Debian’s Release Process
Debian’s Release Process
Debian’s release engineering pipeline is renowned for delivering “The Universal Operating System” with legendary stability. It relies on a multi-stage repository maturation workflow:
+-----------------------------------------------------------+
| Debian Repository Maturation |
| |
| 1. Experimental: Radical new software & unproven branches |
| | |
| v |
| 2. Unstable (Sid): Continuous landing zone for maintainers|
| | |
| v (Automatic 5-10 day aging + zero RC bugs) |
| 3. Testing (Trixie): Rolling staging ground for next LTS |
| | |
| v (The Release Freeze: Transition, Soft, Hard) |
| 4. Stable (Bookworm): Production release (Supported 3-5y) |
| | |
| v (Security Team Backports Only) |
| 5. Oldstable / LTS: Handed over to Debian LTS Team |
+-----------------------------------------------------------+
The Automatic Migration from Unstable to Testing
Debian packages do not move from unstable to testing manually. A software robot named britney manages automated migration: - The package must be present in unstable for at least 5 days (or 2 days for urgent security uploads). - It must have been compiled successfully across all officially supported release architectures. - It must have zero Release-Critical (RC) bugs filed against it in the Debian Bug Tracking System (BTS). - Its installation must not break any existing packages in testing.
The Three Phases of the Release Freeze
Approximately six months before a new Debian Stable release is published, the Release Team institutes progressive freezes: 1. Transition Freeze: Maintainers are forbidden from starting new library transitions that alter shared object sonames. 2. Soft Freeze: No new source packages can enter testing. Only bugfix updates to existing packages are permitted. 3. Hard Freeze: Every individual package upload into testing requires explicit approval and review by the Debian Release Team.
Once the total count of Release-Critical bugs reaches zero, the current testing branch is tagged as stable.