Re: Shortening release cycles
Note that this would require a lot more disk space for our archives
than the current system. Even more than the package pool proposal
would (and disk space/mirror resources has been one of the biggest
problems with implementing package pools).
On Mon, Sep 13, 1999 at 11:02:16PM +0200, Rene Mayrhofer wrote:
> 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 Mayrhofer
> mailto: firstname.lastname@example.org
> To UNSUBSCRIBE, email to email@example.com
> with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org