[lkml]   [2005]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: RFD: Kernel release numbering
Hi Linus,

For a long time, I've been hoping/asking for a more frequent stable/unstable
cycle, so clearly you can count my vote on this one (eventhough it might
count for close to zero). This is a very good step towards a better stability

However, I have a comment :

> - 2.6.<odd>: still a stable kernel, but accept bigger changes leading up
> to it (timeframe: a month or two).
> - 2.<odd>.x: aim for big changes that may destabilize the kernel for
> several releases (timeframe: a year or two)
> - <odd>.x.x: Linus went crazy, broke absolutely _everything_, and rewrote
> the kernel to be a microkernel using a special message-passing version
> of Visual Basic. (timeframe: "we expect that he will be released from
> the mental institution in a decade or two").

I don't agree with you on this last one (not the fact that you don't want
an mk+mp+vb combination :-)). The VERSION number (in the makefile meaning of
the term) only gets updated every 10 years or so. So it does not need to
jump. PATCHLEVEL increments are rare enough to justify lots of breaking.
I certainly can imagine people laughing at your OS when you jump from v2.6.X
to v4.0.X, it will have a smell of slowaris (remember 2.6 - 2.7 - 7 - 8 that
confused everyone ?). On the other side, the openbsd numbering scheme is far
simpler to understand, and I sincerely think that we should enter 3.0 after
2.8. As a side note, I've always wondered why we would not swap odds and
evens, so that we can keep the same major number between devel and release
(eg: devel 2.8, release 2.9 ; not devel 2.9, release 3.0). Anyway, people
have got used to stay away from the '.0' releases of any product on the


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:10    [W:0.446 / U:5.460 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site