I suggest that major and minor versions follow some milestones (as suggested
to a message that I cannot reply directly). For example:
Starting from 'today', mark all open bugs and change version to 2.7 when all
those bugs are closed. Then mark the open bugs of that time and change to 2.8
when those bugs are fixed. Repeat as needed.
Set a 'target'/goal and change version to 3.0 whenever worldwide linux
server/desktop percentage reaches XX%. (Of course this may happen before
changing to 2.7 but this is not a bad thing (tm)). Then set another target
(that may not be related to linux adoption) etc, etc...
This will keep the current versioning scheme, set some common goals for all
developers, add more meaning into trying to fix bugs and prevent the world
from experiencing large linux version numbers.
As a side-effect, setting targets like those may make the whole community
cooperate even more/better by having common long-term goals.
...
p.s You could also keep the X.Y.Z notation and change the major version
number whenever the way of versioning changes (and the current one is
actually version 2) :P
--
