Debian's archive is organised into stable, testing and unstable (sid). What is each suite for, and by what rule does a package move from unstable into testing and eventually into a stable release?
answer
- three suites, one direction of travel
- nobody uploads into the middle one
- age plus no new release-critical bugs
- an automated migration script, not a vote
- freeze turns the middle one into stable
basics
~20 sDebian uploads always land in unstable (sid) and migrate automatically into testing after a few days without new release-critical bugs and with builds on every release architecture. Testing is periodically frozen and published as the next stable.
solid answer
~50 sDebian keeps one archive with several suites. Every maintainer upload goes into **unstable**, which is permanently codenamed *sid* and is never released. **Testing** is a staging suite nobody uploads to directly: a package migrates there automatically once it has spent a minimum number of days in unstable, has no release-critical bugs that the version already in testing lacks, has been built for all release architectures, and its dependencies can move with it. Ahead of a release the release team freezes testing in stages, restricting migrations to targeted and then release-critical fixes only; when the freeze ends, testing is published as the new **stable** under its codename and the previous stable becomes *oldstable*. sid keeps its name across the whole cycle. Debian releases when the freeze is judged done rather than on a calendar date, which in practice has meant roughly every two years.
go deeper
Be able to name the three suites, say that uploads go to unstable, and state that testing eventually becomes the next stable. Knowing that sid is the permanent name of unstable already puts you ahead of most candidates.
Explain the migration conditions in your own words — a minimum age in unstable, no new release-critical bugs, built on all architectures, dependencies able to move together — and describe what the pre-release freeze restricts.
Show that you configure fleets against codenames rather than the stable alias, and be ready to say why testing is a poor server target despite being more current: no direct path for urgent fixes and no reproducible install point.
Own the argument that Debian's gate is evidence-driven automation rather than human judgment, and discuss what that buys you: predictable installability, but a release date nobody can promise in advance, which has to be reflected in your own platform roadmap.
## The suites Debian ships one archive containing several *suites*, and a machine's sources decide which suite it tracks. - **unstable** is where every new upload lands. It is permanently codenamed **sid** and is never released as a product. "Unstable" describes its integration status, not its code quality: the software is usually the maintainer's latest good work, but it has not yet been tested against the rest of the archive. - **testing** is the staging suite. No one uploads to it. Packages appear in it only by *migration* from unstable. - **stable** is the released distribution. It carries a codename and a number, and the version of every package in it is frozen for the life of the release. - **oldstable** is the previous release, still supported for a while after the new one ships. - **experimental** is a holding pen for uploads too disruptive even for unstable; nothing migrates out of it on its own. ## How a package enters the archive A maintainer builds a *source* package and uploads it for unstable. Debian's autobuilder network compiles that source for each release architecture, producing the binaries. The package then sits in unstable and accumulates evidence about itself: build results and bug reports from the people who run sid. ## The migration rule The release team runs an automated migration tool (historically called *britney*) that repeatedly asks, for each candidate in unstable, whether it may replace what is currently in testing. The usual conditions are: - **Age.** It has been in unstable for a minimum number of days. The urgency declared in the upload sets that window — roughly ten days for low urgency, five for medium, two for high. - **No regressions.** It must not carry release-critical bugs (severities *serious*, *grave*, *critical*) that the version already in testing does not have. - **Built everywhere.** Binaries must exist for every release architecture, from that same source version. - **Dependency closure.** Everything it needs must already be in testing, or must be able to migrate in the same batch. Library transitions therefore move as a group, not one package at a time. - **Not blocked.** The release team can pin a package back deliberately. Nothing here is a human promotion decision. It is an automated, evidence-driven gate, which is why testing is normally installable: a package that broke something simply never gets in. ## The freeze and release day Before a release, testing is frozen in stages — large transitions stop first, then only targeted fixes are accepted, then only release-critical fixes reviewed by the release team. Migration from unstable is largely closed during the freeze. Debian publishes when the release team judges the work done, not on a fixed date; historically that has been about every two years. On release day, testing is published as the new stable under its codename, the previous stable becomes oldstable, a new testing is seeded, and migration reopens. sid is untouched by all of this and keeps its name — a common misconception is that sid gets renamed the way testing does. From that day, the stable suite's package versions stop moving. Fixes are backported into those frozen versions and published through the security suite and the periodic point releases. ## What this looks like in a sources file ``` deb http://deb.debian.org/debian bookworm main deb http://deb.debian.org/debian bookworm-updates main deb http://security.debian.org/debian-security bookworm-security main ``` You may write either the codename (`bookworm`) or the alias (`stable`). The difference matters operationally: a machine tracking `stable` silently changes release the day a new stable ships, while a machine tracking a codename stays where it is until you edit the file. Fleet configurations normally pin the codename for exactly that reason. ## Why interviewers ask this The branch model explains nearly everything else about Debian: why stable ships versions that look old, why security fixes arrive as a Debian revision bump rather than an upstream upgrade, why backports exist as a deliberate escape hatch, and why "just run testing on the server" is a weak plan — testing has no direct upload path for urgent fixes, so a fix must land in unstable and migrate before it reaches you.
- Why is unstable always called sid, while testing and stable get new codenames each cycle?sid is a permanent rolling suite: it exists continuously and every upload targets it, so it has no release identity to name. Testing and stable are snapshots of a particular release cycle, so each cycle's testing carries the codename it will keep once it is published as stable. Renaming sid would imply it ships, which it never does.
- Why is running testing on a production server usually a bad idea, even though it is more current than stable?Testing has no direct upload path for urgent fixes. A security patch must first land in unstable and then satisfy the migration rules, so testing can lag stable for a serious issue. It also changes continuously, so two machines installed weeks apart are not the same platform. For servers you generally want stable plus backports for the few packages that genuinely need to be newer.
- What is a transition, and why does it slow migration down?A transition is a change — typically a library soname bump — that requires every package depending on that library to be rebuilt. Migration is only allowed when the whole set can move together, since letting the library in alone would leave testing with unsatisfiable dependencies. The release team coordinates these as a batch, which is why a single library upload can hold up dozens of packages for weeks.
saying these in an interview costs you the question
- Thinks maintainers upload new packages directly into testing
- Says sid is renamed to the next codename at each release
- Believes a human release manager promotes each package by hand
- Claims stable receives new upstream versions between releases
- Assumes unstable means the software is broken rather than unintegrated