[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48F692E9.2080008@zytor.com>
Date: Wed, 15 Oct 2008 18:03:37 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Greg KH <greg@...ah.com>
CC: Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: [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.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists