Re: Shortening release cycles
On Sun, 12 Sep 1999, Andrew G . Feinberg wrote:
> When we release a new stable, we immediatly set goals for the next stable
> (FHS, PAM, etc.) Why do we need to have 2.1 2.2 2.3 3.0 etc?
I think this idea is interesting, for it could address the problem
of whether to release an updated Slink, or go straight for Potato.
Thinking out loud, the version numbering scheme could be changed to
reflect a new way of thinking, where each version is split into a
`paradigm' and a `release'.
A `paradigm' (the most major part of the version number) would reflect
a collection of policies and goals and styles; for instance Hamm's
paradigm might be non-FHS, non-PAM and dpkg, whereas Slink's paradigm
would be non-FHS, non-PAM, glibc 2.0, kernel 2.0 and apt, and Potato's
paradigm would be FHS, PAM, glibc 2.1, kernel 2.2 and apt. A paradigm
would be defined mainly, I suppose, by a full collection of packaging
and policy manuals.
The `release', on the other hand, would simply refer to the versions
of the packages included, so that if the current release in the
`Slink' paradigm starts looking old, a newer release, with bang up-to-
date packages can be made in the Slink paradigm. Releases could be
made simultaneously in both paradigms, with one marked "stable" and
another "unstable", so that the daring can fetch all the latest
packages with PAM, FHS and Linux 2.2, whereas the meek can simply
stick with their trusted Slink paradigm, but still with all the very
latest packages.
Releasing in two paradigms simultaneously would be easier than one
might imagine; bugs in the database can be classified according
to the paradigms they affect, and bugs common to both can be
tracked easier. Certain packages can be paradigm-specific, such as
boot-floppies, and some of the DDP manuals.
Of course, the build system would need a lot of attention to make
it to this level, but not unduly much, I think, given that the
build system is reasonably complex already.
This may sound crackpot or stupidly elaborate as an idea, I admit,
but I don't think this updated-Slink/new-Potato problem is going
to just be a one off -- I think this sort of thing is going
to happen more than once. And rather than having to make a hack
out of it every time, or an unannounced regression in functionality
so that a release can be made, if Debian took this sort of thing in
its stride, one would hope it would create less tension.
Of course, maintainers may not like the idea of maintaining a
hacked-about source tree, so perhaps there are other ways of
dealing with this: perhaps a smallish team can be assigned to
work on the currently "stable" paradigm, leaving the developers
free to forget about maintaining compatbility with old versions
of their packages, and the tightly-knit team free to get to
know the distribution better.
Anyway, it's 6 AM, so I'll leave it there. Now rip to shreds. ;-)
--
Chris <chris@fluff.org> ( http://www.fluff.org/chris )
Reply to: