On Sunday, 19 of October 2008, david@xxxxxxx wrote:On Sun, 19 Oct 2008, Rafael J. Wysocki wrote:
On Sunday, 19 of October 2008, Jiri Kosina wrote:On Fri, 17 Oct 2008, david@xxxxxxx wrote:
Surely some scripts will start to break as soon as the third number getswe've had three digit numbers in the third position before (2.3 and 2.5
went well past three digits IIRC)
Did we? I only recall 2.5.7[something] and 2.3.5[something] (plus special
Actually, I thought we could continue to use a w.x.y.z numberingif you want the part of the version number to increment based on the year,
scheme, but in such a way that:
w = ($year - 2000) / 10 + 2 (so that we start from 2)
x = $year % 10
y = (number of major release in $year)
z = (number of stable version for major release w.x.y)
Then, the first major release in 2009 would be 2.9.1 and its first
-stable "child" would become 220.127.116.11. In turn, the first major
release in 2010 could be 3.0.1 and so on.
just make it the year and don't complicate things.
In addition to that, having the kernel version dependent on year doesn't
really seem to make much sense to me. Simply said, I don't see any
relation of kernel source code contents to the current date in whatever
And 2.x+1.y-rcZ+1 immediately following 2.x.y-rcZ really hurts my eyes :)
Hm, why would that happen?
with the date based numbers, that was one of the things that 'could'
happen as the year changed (2008.5.0-rc4 would be followed by
Well, in that case I think it would be reasonable to cuntinue the 2008
numbering so that 2009.1.0-rc5 in your example would still be 2008.5.0-rc5.
That said, I kind of agree that the numbering need not be time-related. One
alternative might be to release 2.9.0 instead of 2.6.29 and then continue in
in such a way that each of the three numbers is always a one-digit decimal.
Then, we'd have 2.9.0, 2.9.1 ... 2.9.9, 3.0.0, 3.0.1 etc.