"Deven T. Corzine" <deven@ties.org> writes:
> 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.
2.3.xx isn't supposedly stable, just hopefully stable -- it would have
an even minor number if it were really supposedly stable.
> 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
The problem the entire scheme is that the version numbers are not
strictly related to how development is done (yet they're supposed to
strictly describe the development state). I've been around to see the
2.1.xx and 2.3.xx trees be started, develop, and mature. In both
cases there was 'feature freeze', 'code slush', and 'code freeze'
.. followed by a bunch of new features getting in, and going back to a
'feature slush' before progressing to 'code freeze' state. 2.1.xx
even repeated this cycle, having THREE points (that I remember) where
it entered 'code freeze.' The reversions from 'code freeze' to an
earlier state usually allowed newer patches to be incorporated even if
they had not been accepted during the 'code freeze' state.
Also, if you think about it, different parts of the kernel aren't
necessarily at the same point in their respective development cycles,
although they are roughly synchronized. For example, even in 2.3.xx's
first code slush, new USB drivers were being added and the architecture
being revised because the USB support was otherwise very lacking.
If those two reasons aren't enough, I find the idea of having four
parts to a version number extremely annoying. It's much easier and
more practical to continue describing the releases as Linus has done
in the past: with external descriptions of the criteria for changes
being made. Sometimes these criteria do follow the 'open
development,' 'feature freeze,' 'code slush,' 'code freeze,' 'release'
progression. More often, they don't (even if one of those terms was
used to describe the release).
As an example, take the stable kernel series: New stuff gets in,
although the stability criteria are much higher for these additions.
It wasn't really until 2.2 was out that 2.0 became bugfix-only;
likewise, 2.2.15 adds some new features even as 2.4 seems to be
knocking on the door.
Michael
P.S.: What does 2.5.9.xx correspond to now, anyway? Once 2.4.0 is
out, there will be no further development on 2.3.x, and thus no need
to release new kernels in that series. There wasn't really anyone
tinkering on 2.1.x code bases once 2.2.0 came out.
-
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:16 EST