Re: Shortening release cycles

[Rene Mayrhofer <rmayr@vianova.at>]

On Mon, 13 Sep 1999 Chris Rutter wrote:
> 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.
I fully agree with this.

Rene

-- 
Rene Mayrhofer
mailto: rmayr@vianova.at