Differences between revisions 1 and 13 (spanning 12 versions)
Revision 1 as of 2004-12-27 02:44:19
Size: 540
Editor: anonymous
Comment:
Revision 13 as of 2009-03-16 03:33:08
Size: 1590
Editor: anonymous
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## Auto-converted by kwiki2moinmoin v2005-10-07
This is the current philosophy behind Debian's release process.
#language en
[[D
ebianReleases]] > Release When Ready
----
This was the philosophy behind Debian's release process.
Line 7: Line 9:
 * We know that this works and results in releases of consistently high quality.  * First of all, we __do__ release; releasing is important for our development process.
 * Releases are of high quality (because we always sacrifice promptness instead).
 * Compared with releases that are split up, monolithic releases are easier to support.
 * Compared with short release intervals, long release intervals reduce the number of releases that have to be supported, allowing us to do a better job of supporting the releases that we do make. Long release intervals also make it reasonable for us not to support skip-upgrades, which simplifies package maintenance.
Line 11: Line 16:
 * This worked better when Debian was small. The time between releases has been steadily increasing over the past several releases using this method.
 *
 * This worked better when Debian was small. The larger Debian becomes, the harder it becomes to get all of it in shape at the same time.
 * As a result, the time between releases has been steadily increasing.
 * The long interval between releases has driven people to use sid or other distributions.
 * Even among defenders of ReleaseWhenReady, many people think that sarge has taken too long to release and that __something__ must be done to make sure that etch is released more quickly.
Line 15: Line 22:

------
'''Note to wiki editors''' / !PermaLink : If you want to link to the current release policy, link to the redirect-page [[ReleasePolicy]] rather than linking to this page statically.

DebianReleases > Release When Ready


This was the philosophy behind Debian's release process. Release only when everything is ready, meaning that all the infrastructure is in place, and the number of release critical bugs is zero.

Pros:

  • First of all, we do release; releasing is important for our development process.

  • Releases are of high quality (because we always sacrifice promptness instead).
  • Compared with releases that are split up, monolithic releases are easier to support.
  • Compared with short release intervals, long release intervals reduce the number of releases that have to be supported, allowing us to do a better job of supporting the releases that we do make. Long release intervals also make it reasonable for us not to support skip-upgrades, which simplifies package maintenance.

Cons:

  • This worked better when Debian was small. The larger Debian becomes, the harder it becomes to get all of it in shape at the same time.
  • As a result, the time between releases has been steadily increasing.
  • The long interval between releases has driven people to use sid or other distributions.
  • Even among defenders of ReleaseWhenReady, many people think that sarge has taken too long to release and that something must be done to make sure that etch is released more quickly.

See ReleaseProposals for alternatives.


Note to wiki editors / PermaLink : If you want to link to the current release policy, link to the redirect-page ReleasePolicy rather than linking to this page statically.