Re: Temporal Release Strategy
Patrick A. Ouellette wrote:
>The progression I see is:
>
>unstable -> testing -> candidate -> stable
>
>
Unfortunately this totally changes the purpose of "stable". Stable is
there not to provide bug free, up-to-date software releases. Stable is
to provide environmental stability. When someone installs package X from
stable, it is guaranteed that this package will remain at version X
though all security updates, etc.. It will remain as is, bugs and all.
This has a few disadvantages and advantages. The main advantages include,
* less time spent on maintaining your production machines - once you set
them up, no need to change the configs.
* ability to maintain 1000s of installations by one person - installing
a new machine can be as simple as `dd` the partition.
* security fixes do not break your system (3rd party applications or
otherwise)
The main disadvantage of this is that stable becomes stale.
The current testing is a remedies for this problem. Up-to-date packages
are provided in testing where the packages are virtually always
production quality. The main disadvantage of testing is lack of
environmental stability seen in stable.
The only difference between the support of testing vs. stable in Debian
is security support. If we have volunteers for the security team for
testing (for Etch), then I'm certain Debian can have two release modes,
stable -> environmental stability implying stale packages
testing -> up-to-date packages implying more work by admins
So, if we get testing-security working, then we will essentially have
two releases.
We should not destroy the notion of stable to get up-to-date packages.
- Adam
Reply to: