Re: [RFC] Kernel version numbering scheme change

[H. Peter Anvin]

Greg KH wrote:
> Yes, we can handle the major/minor macros in the kernel to provide a
> compatible number so that automated scripts will not break, that's not a
> big deal.
>
> Any thoughts?
>
> Let the bike-shedding begin!

Personally I find that having a simple counter is kind of nice, simply 
because one can talk about 27, 28, 29, ... and actually be able to rely 
on it being stable.

The 2.6 prefix has clearly outlived its utility.  The easiest way to 
deal with that is of course to simply drop it, but perhaps the best 
thing to do would be to bump the major number to 3, and start out with 
3.0 instead of 2.6.28, 3.1 for 2.6.29 and so on.  This has the advantage 
that we still retain the major number for "huge changes".

On the other hand, a number of projects have gone to simple counters for 
version numbers, without a leading major.  Just having *one* number (or 
two for point releases) compensates to a large degree for the numbers 
being large.  Given that, we could just make it version 3 instead of 
2.6.28, 4 instead of 2.6.29 and so on.

	-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/