[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Temporal Release Strategy

Since I first became involved with Debian (1997 ish), people have
complained about the slow release cycle.  This has caused me to draw the
conclusion that there will always be someone who complains about the
frequency (either slow or fast) of official releases.


The advent of testing and package pools held the promise to shorten the
release cycle and improve the stability of the Debian stable release.
The debate can rage on in other circles as to the success or failure of
that statement.

There may be another way.  The institution of package pools has
essentially reduced the concept of a release to a package index file
generated on a particular day.  As long as the packages listed in the
Packages.gz file are available in the package pool, that Packages.gz
file describes a "release."  The "release" may not be stable, and may
contain many RC bugs, but it is a definite, reproducible collection of
packages that can be installed.

The automated progression of packages from unstable to testing has made
testing a viable distribution for many users.  That is not to say
testing is suitable for all users and all tasks, but rather that testing
is frequently "stable enough" for many uses.  I will venture to say the
promotion process from unstable to testing is an unqualified success.


I suggest we can eliminate the traditional concept of a "release"  with
the addition of another step in the progression from unstable to
stable.  Additionally, all promotion of packages from one step to the
next will be automated according to strict rules.

The progression I see is:

unstable -> testing -> candidate -> stable

The existing rules for promotion from unstable to testing continue to be

Promotion from testing to candidate requires meeting the same rules as
promotion from unstable to testing with the following exceptions:
packages must be in testing for at least 3 months, and have no release
critical bugs.

Promotion from candidate to stable would follow a similar pattern, with
a time in candidate requirement of 3 additional months.

Security updates are then provided for packages for 36 months after they
have been replaced with a newer version in stable.

No changes are made to experimental.

CD image generation can be run from any stage.  I would suggest monthly
image creation from candidate, and quarterly generation from stable.

For purists who insist on "blessing" a collection of packages proven to
work together with a release name & number, they can be satisfied if we
"release" driven by content changes (new libc, new desktop, whatever)
instead of the calendar.



Patrick Ouellette
Amateur Radio: KB8PYM 

Attachment: signature.asc
Description: Digital signature

Reply to: