Re: Debian versioning scheme (r1 vs .1)
Joel Baker <email@example.com> wrote:
> In other circles, "we have six months until we try to release again" means
> that if the installer takes 18 months to write, you assume that you do not
> have it for 3 release cycles.
Iirc nobody was willing to maintain boot-floppies for another release.
> Other things may happen to cause the cycle to
> slip, often unforseen (and exceeding normally accounted for) last-minute
> delays, but they don't *assume* that 18 months is a viable release cycle.
> And it is proven to function, and work. Debian's method is also proven
> to function, and work... up to a point. I say that empirical evidence
> indicates that we have reached the point where it is no longer tenable as
> it is.
> Prior to Woody, I heard the refrain "testing will fix this, but it hasn't
> had a chance to sit between major releases to prove it". Okay, valid
> argument. Now that it's sitting between major releases, it may well be
> true that we could freeze and release much faster (having not yet tried
> to do it, I can only say 'it appears likely'). So we... make choices that
> guarantee another 2-year release cycle.
That is too simple. In every release cycle there seems to be at least
one major thing that has to get in and needs more than 6 months for
implementation and proper testing with a big audience. Take e.g. the
gcc-3.2 transition or every perl-update. Debian has neither got
the resources nor the *testers* to move this part to separate trees
(unstable_gcc3.2", unstable_perl5.8, unstable_gcc3.2+perl5.8,
"unstable - the release-candidate.")
> another developer noted that much of the pressure to actually get a
> release out the door seems to have vanished, with the advent of
You might be correct.
 BTW, how is its status?
Hey, da ist ein Ballonautomat auf der Toilette!
Unofficial _Debian-packages_ of latest unstable _tin_