(This message is long, but hopefully interesting? Please read it!)
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...
The Linux kernel established the current scheme with version 1.0, and it
has been widely copied since. (Was it used before then by anyone else?)
Even numbers in the version number for stable releases and odd numbers for
development releases has worked quite well. This encodes some meaning into
the version number, which makes the status of kernel versions easier to
identify. I'd like to extend this further by adding a digit to development
version numbers representing the current phase of the development cycle.
This is easiest to explain by way of an example proposal:
2.4.xx Current stable release series. (Well, almost current.)
2.5.0.xx Initial integration -- No architectural changes allowed
while the inevitable backlog of pending patches from the
last stabilization effort are integrated and stabilized.
The final 2.5.0.xx release should be re-released as a new
2.4.1 stable release. This series should resemble a
combination of 2.5.8.xx and 2.5.9.xx below, and should be
suitable for non-mission-critical production use. This is
a fork from the stable series that re-merges once before
diverging again for radical development work.
2.5.1.xx EXTREMELY unstable -- Major architectural changes, any new
features and major feature changes allowed as the tree is
thrown wide open for bizarre and wild experimental work,
much of which may be discarded as experimental prototypes
prove that some ideas that sounded good weren't so good.
Suitable only for the extremely brave or foolish. Even
developers may wish to avoid this series unless they're
doing the experimenting. Expect constant crashing.
2.5.2.xx VERY unstable -- Much like 2.5.1.xx series, but experiments
should a little less wild now. Best time to focus on the
major architectural changes that are goals for the 2.6.xx
stable series. Most developers would want to work with
this series, but not depend on it heavily for daily use.
Expect nearly constant crashing.
2.5.3.xx Unstable -- Significant architectural changes, new features
and major feature changes allowed. Most experimental work
should be finished by now; new experimental work should be
developed in a forked tree until suitable for integration
into development tree. Suitable for developers, should be
stable for short periods of time. Expect frequent crashes.
2.5.4.xx Almost stable -- Reasonable architectural changes allowed,
new features and major feature changes allowed. Suitable
for developers only, but "bleeding edge" users may want to
try it out briefly. Expect random crashes, but should be
stable enough to be more-or-less usable.
2.5.5.xx Somewhat stable -- Small architectural changes allowed,
new features and significant feature changes allowed.
Suitable for developers and "bleeding edge" users only.
Expected to crash once or twice per day, but should be
stable for hours at a time.
2.5.6.xx Reasonably stable -- Minor architectural changes allowed,
medium feature changes allowed. Suitable for experimental
servers or the more patient of the average desktop users.
Not suitable for any production use; may crash several
times per week.
2.5.7.xx Mostly stable -- No architectural changes allowed, new
features and small feature changes allowed. Should be
suitable for the average desktop user or for a test server.
Not suitable for most production use; expected to crash
every few weeks or so.
2.5.8.xx Initial release candidates -- No architectural changes, and
only minor feature changes or clean new features allowed.
Bugfixes and carefully selected patches only. Should be
suitable for production use only on non-mission-critical
systems. (This series would be equivalent to "pre" series
in the past preceding a new stable release series.)
2.5.9.xx Final release candidates -- No architectural, new features
or feature changes allowed at all. Bugfixes ONLY; final
tuning before 2.6.xx stable release series. Final release
candidates should be almost suitable for production use on
mission-critical systems, as any stable series release
should be. (This depends on getting 2.5.8.xx used on some
production systems first...)
The 2.5.9.xx series should REPLACE the traditional initial
stable series stabilization efforts. The final release in
this series should be re-released as 2.6.0 and 2.7.0.0 with
no changes but the version number -- if more bugfixes are
needed, it's not time yet. Only when it's time to fork for
a new development series should the stable series be
declared. (This should avoid embarassments like 2.2.0 --
a "stable" release that crashed rather easily...)
2.6.xx Next stable release series.
-
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