[lkml]   [2008]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] Kernel version numbering scheme change
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.


 \ /
  Last update: 2008-10-16 03:07    [W:0.254 / U:11.620 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site