Re: Version numbering proposal (2.5.x.xx)

From: Deven T. Corzine (
Date: Wed May 10 2000 - 08:36:13 EST

On Wed, 10 May 2000, Adam wrote:

> On Wed, 10 May 2000, Deven T. Corzine wrote:
> > An idea for a "variation on the theme" for version numbers occurred to me a
> > while back, but with 2.4 coming soon, this seems like an opportune time to
> > suggest it and see if anyone likes it...
> > I'd like to extend this further by adding a digit to development
> > version numbers representing the current phase of the development cycle.
> Well, the way I see Linux Kernel development for past years, the
> suggested numbering does not reflect the way kernel is developed.
> We have something like, we add bunch new patches, stabilize thing so it is
> usable, then add another bunch of patches, again stabilize things a bit,
> then yet another bunch of patches, and so on during a single new kernel
> development cycle. Also patches are submited at various stages of
> devlopment. This is possible since some of them are developed outside of
> kernel, we we as well end up having a bunch of new patches at end of
> development. Finally, "disasterous kernels" happen at ANY stage of
> development. For example the 2.3.99-pre2 was corrupting data for me. And
> this is supposedly stable kernel.

That's true, but it would help to have some sense of where the kernel is
intended to be. I think that there *are* phases corresponding to 2.5.6.xx
through 2.5.9.xx from the proposal I gave, but they aren't represented the
same way. Here's about how I see the correlation:

     Proposal Existing Approach
     -------- -----------------
     2.5.6.xx "We're gonna have a feature freeze for 2.6.0 soon, get
                 your patches in while you can!"

     2.5.7.xx "We are officially under a feature freeze, but we may take
                 a few clean patches if they're well-justified."

     2.5.8.xx "These are pre-releases for 2.6.0, and we're dead serious
                 about the feature freeze -- bugfixes ONLY!"

     2.5.9.xx "Okay, 2.6.0 is out -- we'd better stabilize it when it
                 starts getting massively used, because we probably missed
                 something that will be discovered in production. We'll
                 have to wait a bit before forking 2.7.0 for new work."

I'm just trying to suggest a way to codify these phases a bit better, so
that expectations will match reality. Granted, my suggested 2.5.1.xx
through 2.5.5.xx series are more vague, and any of them could crash at any
time, but I was thinking that the expected level of stability could still
be indicated -- anyone using development kernels should be prepared for
unexpectedly-unstable releases like 2.3.99-pre2 was for you...


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

This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:15 EST