On 10 May 2000, Michael Poole wrote:
> "Deven T. Corzine" <deven@ties.org> writes:
>
> > On Wed, 10 May 2000, Adam wrote:
> >
> > > [...] 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.
It's certainly intended to be stable, but it's called "pre" if we're not
quite convinced yet. This "pre" suffix just seems unnecessarily confusing.
> 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.
They're not supposed to strictly describe the development state, just to
give an idea of the intended state. Exceptions are always possible, like
the 2.3.99-pre2 example. It was intended to be stable, but wasn't for him.
Anyway, I was making a sample proposal. It may need some tuning. If there
need to be several phases of new-feature/feature-freeze/code-freeze cycles,
the model could be adapted.
Off the top of my head, based on your description, here's a possible one:
2.5.4.xx - new feature work
2.5.5.0 - initial feature freeze
2.5.5.xx - initial code slush
2.5.6.0 - initial code freeze
2.5.6.xx - new feature work
2.5.7.0 - final feature freeze
2.5.7.xx - final code slush
2.5.8.0 - final code freeze
2.5.8.xx - initial release candidates
2.5.9.xx - final release candidates, encourage non-critical production use
2.5.2.xx and 2.5.3.xx could either be another (earlier) round of feature
work/slush/freeze, or fewer categories of earlier stages of stability.
Either way, 2.5.1.xx could remain wild experimental stuff.
I'm not suggesting the initial proposal was the One True Way to number
versions, just that the version numbers could be extended to represent
expectations of the current development cycle. If multiple feature work/
slush/freeze cycles work better, that could be done too.
On the other hand, Linus has said he wants a faster cycle from one stable
release series to the next, in which case the original proposal could be
considered the expansion of a single feature work/slush/freeze cycle...
(The main reason to define every number 0-9 is to avoid gaps in the
sequence, but that isn't strictly necessary; it could jump from .1 to .6 if
that works better.)
> 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.
That rough synchronization is all you'd be trying to represent with the
version number -- you can't get it 100% accurate.
> 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).
You could do that with single trees too, and that used to be more common.
When Linus split stable versions from development versions, it eliminated a
lot of confusion and made things a lot clearer. I'm hoping this could do
the same to eliminate confusion about the development cycle. (It also
makes it easier to reject large changes too late in the cycle -- "that
should have been done back in 2.5.2.xx"...)
> 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.
I'm think 4-part version numbers might help on the stable side for this.
Normal 3-part versions would be the "stable" versions (e.g. 2.6.2) while
"almost stable" versions would be 4 parts (e.g. 2.6.2.3) -- then someone
who wants a rock-solid kernel for a mission-critical server would never
touch the 4-part "almost-stable" versions, until they get "blessed" into
the next 3-part version. For example, say that 2.6.2 is rock-solid, and
2.6.2.1 has new features that should be stable (but may have bugs). The
2.6.2.xx series would be a feature work/slush/freeze cycle (as in the
development tree) between the rock-solid 2.6.2 and 2.6.3 versions.
How would that work out?
> 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.
In the proposed scheme, 2.5.9.xx would correspond to what would have been
early 2.6.0 releases before forking 2.7.0. In other words, people would be
encouraged to use 2.5.9.xx kernels for production use, but not for any
mission-critical use yet.
Maybe this is too much to ask of production sites -- too many would be
inclined to wait for 2.6.xx instead. Anyone with mission-critical system
and a clue would avoid 2.6.0 anyway, waiting for 2.6.1 or later. In that
case, the original 2.5.9.xx proposal might not be worthwhile -- renumber
the earlier ones (make 2.5.9.xx the initial release candidates instead of
2.5.8.xx) and be done with it.
Okay, after all these revisions, I'm thinking that all 2.6.xx.xx kernels
would be suitable for production use, but only 2.6.xx kernels AFTER 2.6.0
might be suitable for mission-critical use. (Some sites might want to wait
for 2.6.2 or 2.6.3, depending how paranoid they are.)
I think I'll wait for a few more reactions before rewriting a complete
revised proposal...
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:16 EST