On Tuesday 15 July 2008, Kasper Sandberg wrote: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. --
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Ingo Molnar | Re: [RFT] x86 acpi: normalize segment descriptor register on resume |
| Andrew Morton | -mm merge plans for 2.6.23 |
| Greg Kroah-Hartman | [PATCH 004/196] Chinese: add translation of SubmittingPatches |
git: | |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| David Miller | Re: [GIT]: Networking |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Ingo Molnar | [bug] stuck localhost TCP connections, v2.6.26-rc3+ |
