lkml.org 
[lkml]   [2008]   [Jul]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: From 2.4 to 2.6 to 2.7?
Date
On Tuesday 15 July 2008, Kasper Sandberg wrote:
> I like the current numbering fine.. my suggestion is to keep the current
> model, there are various reasons
>
> 1: it requires no effort
> 2: various things doesent break
> 3: naming isnt _THAT_ important

Sorry for entering a discussion from a project I'm just a user of, but I was
thinking... I do see smallish problems with current scheme:

- First two numbers never change (2.6), so they're mostly useless.
- Third number gets too big (currently 26, and growing)
- Stable releases are already a fourth number (2.6.25.11. Unconfortable).

So a possible solution that would not break completely with historical numbers
could be:

- Since you're aproaching 2.6.30 (around mid 2009), why not agree tu turn that
into a 3.0 release? Peope have been expecting a version 3 of the kernel for a
long time now... It might give the (false) impression that it's an all new
release, but it would be explained that it's just a normal one. However, I
also think that by that time, the last "problem" with Linux will be solved,
i.e, the graphics thing. With the changes in DRM/DRI starting to appear in
2.6.27 (maybe), they will stabilize through .28 and .29, making .30 a good
release to declare the Linux kernel "completely mature", without any weak
spot (so to say) and turn it into 3.0 release (the Free drivers for ATI and
even NVIDIA will hopefully be mature by then too, as might be Gallium3D,
VA-API, GEM/TTM, etc... )

- From there, how to proceed? Instead of making the same mistake again of
having a useless middle number, each release would increment by a 10th. That
is, instead of 3.0.1, 3.0.2, etc... just 3.1, 3.2, 3.3, etc... Then the stable
releases would be 3.1.1, 3.1.2, etc... (no longer a 4 series of numbers). And
after 3.9, we would have 4.0 to avoid having again a too bit number (3.26,
etc...). Roughly, you release 5 kernels per year, so that would give enough
time until you hit a high number (it will increment by one every two years).
For example, it would take 20 years from 2009 until you hit version 13.0.
Twenty years is a decent amount of time in kernel development. And well, even
13 is not _that_ big anyway. You can push this numbering up to version 20 if
necessary and that would give another 14 extra years. By then (year 2043) I'm
sure that someone will have come up with a smart way of rearranging the
numbering once more :-)

Regards.



\
 
 \ /
  Last update: 2008-07-19 05:17    [W:1.804 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site