Re: On Linux numbering scheme

[Arnd Bergmann <arnd@arndb.de>]

On Saturday 08 January 2011, Artem S. Tashkinov wrote:
> However sources of VMWare/NVIDIA/VBox/etc. kernel modules have multiples
> instances of:
> 
> #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 4, 7)
> #  error This driver does not support 2.4 kernels older than 2.4.7!
> #elif LINUX_VERSION_CODE < KERNEL_VERSION(2, 5, 0)
> #  define KERNEL_2_4
> #elif LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 0)
> #  error This driver does not support 2.5 kernels!
> #elif LINUX_VERSION_CODE < KERNEL_VERSION(2, 7, 0)
> #  define KERNEL_2_6
> #else
> #  error This driver does not support development kernels!
> #endif
> 
> So, it seems like the only obstacle that stops us from starting a completely
> new numbering scheme is proprietary or corporations driven/developed software.

If that was the only obstacle, I'd advocate for using whatever scheme
breaks that code the most ;-)

Seriously, the entire problem is just in perception. The main thing
that's really wrong with the current scheme is that people tend to
see the difference between e.g. 2.6.27 and 2.6.37 as much smaller than
between 2.4.0 and 2.6.0, so there is less incentive to update to the
latest release, while in fact there were three years between the
releases in both cases and we are now a lot more active that we
used to be.

These days, the longterm releases really have the role of the old
even-numbered releases, in the way that distros rely on them for
stability, while the regular releases are used by a relatively small
group of people that are interested in using or developing new
features, like the old odd-numbered development releases.
This analogy ends when you look at the kinds of quality control
we apply to patches going into the longterm or the regular releases, 
compared to old even/odd cycles, but I think it's still useful
to consider it from this viewpoint.

I think it would be good to start the next longterm series with a
new number, since that would send an important message to the
end-users and give us better hopes of having a common longterm
tree for all enterprise and embedded people. It is however still
a lot of time until we need to replace 2.6.32/34/35-longterm, and the
incentive to change a name without any other consequences before
then is pretty low IMHO.

Most importantly, at the 2010 kernel summit it was decided to leave
the numbering alone for now. There certainly wasn't a lack of
ideas for how it should be named (2011/2.7/2.8/3.0/6.37/3.7/...).

	Arnd