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).
--
Raul
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
>
> --
> Rene Mayrhofer
> mailto: rmayr@vianova.at
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: