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...
Deven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:15 EST