Siblings
Debian Stable
The “stable” distribution contains the latest officially released distribution of Debian.
This is the production release of Debian, the one which we primarily recommend using.
Development
Each software package has a maintainer that may be either one person or a team of Debian developers and non-developer maintainers.[220][221] The maintainer keeps track of upstream releases, and ensures that the package coheres with the rest of the distribution and meets the standards of quality of Debian. Packages may include modifications introduced by Debian to achieve compliance with Debian Policy, even to fix non-Debian specific bugs, although coordination with upstream developers is advised.[219]
The maintainer releases a new version by uploading the package to the “incoming” system, which verifies the integrity of the packages and their digital signatures. If the package is found to be valid, it is installed in the package archive into an area called the “pool” and distributed every day to hundreds of mirrors worldwide. The upload must be signed using OpenPGP-compatible software.[123] All Debian developers have individual cryptographic key pairs.[222] Developers are responsible for any package they upload even if the packaging was prepared by another contributor.[223]
Initially, an accepted package is only available in the unstable branch.[123] For a package to become a candidate for the next release, it must migrate to the Testing branch by meeting the following:[224]
It has been in unstable for a certain length of time that depends on the urgency of the changes. It does not have “release-critical” bugs, except for the ones already present in Testing. Release-critical bugs are those considered serious enough that they make the package unsuitable for release. There are no outdated versions in unstable for any release ports. The migration does not break any packages in Testing. Its dependencies can be satisfied by packages already in Testing or by packages being migrated at the same time. The migration is not blocked by a freeze.
Thus, a release-critical bug in a new version of a shared library on which many packages depend may prevent those packages from entering Testing, because the updated library must meet the requirements too.[225] From the branch viewpoint, the migration process happens twice per day, rendering Testing in perpetual beta.[123]
Periodically, the release team publishes guidelines to the developers in order to ready the release. A new release occurs after a freeze, when all important software is reasonably up-to-date in the Testing branch and any other significant issues are solved. At that time, all packages in the testing branch become the new stable branch.[123] Although freeze dates are time-based,[60] release dates are not, which are announced by the release managers a couple of weeks beforehand.[226]
A version of a package can belong to more than one branch, usually testing and unstable. It is possible for a package to keep the same version between stable releases and be part of oldstable, stable, testing and unstable at the same time.[227] Each branch can be seen as a collection of pointers into the package “pool” mentioned above.[123]
One way to resolve the challenge of a release-critical bug in a new application version is the use of optional package managers. They allow software developers to use sandbox environments, while at the same time remaining in control of security.[132][133] Another benefit of a cross-distribution package manager is that they allow application developers to directly provide updates to users without going through distributions, and without having to package and test the application separately for each distribution.[228]