Сначала давайте взглянем на конкретный случай экспериментального дистрибутива: это группа пакетов Debian включающих программное обеспечение находящееся в настоящее время в процессе развития и не обязательно завершённое, что объясняет его имя. Не всё проходит через этот шаг; некоторые разработчики добавляют сюда пакеты для того, чтобы получить обратную связь от более опытных (или храбрых) пользователей .

В противном случае, в этом дистрибутиве зачастую содержатся важные изменения базовых пакетах, интеграция которых в нестабильный выпуск с возможными серьезными ошибками будет иметь критические последствия. Таким образом, это полностью изолированный дистрибутив, его пакеты никогда не переносятся в другие версии (за исключением прямого вмешательства сопровождающего или ftp-мастеров). Кроме того, он не является самодостаточным: в экспериментальном выпуске имеется только подмножество существующих пакетов, а сам выпуск, как правило, не включают в себя базовую систему. Поэтому этот дистрибутив полезен, главным образом, в сочетании с другим, самодостаточным, дистрибутивом таким как нестабильный выпуск.

Let us turn back to the case of a typical package. The maintainer creates an initial package, which they compile for the Unstable version and place on the ftp-master.debian.org server. This first event involves inspection and validation from the ftpmasters. The software is then available in the Unstable distribution, which is the “cutting edge” distribution chosen by users who are more concerned with having up-to-date packages than worried about serious bugs. They discover the program and then test it.

Если они находят ошибки то сообщают о них сопровождающему пакета. Сопровождающий регулярно готовит исправленные версии, которые он загружает на сервер.

Every newly updated package is updated on all Debian mirrors around the world within six hours. The users then test the corrections and search for other problems resulting from the modifications. Several updates may then occur rapidly. During these times, autobuilder robots come into action. The maintainer uploads the package sources (without any precompiled package). The autobuilders take over and automatically compile versions for all supported architectures. Some compilations may fail; the maintainer will then receive a bug report indicating the problem, which is then to be corrected in the next versions. When the bug is discovered by a specialist for the architecture in question, the bug report may come with a patch ready to use.

Немного позже пакет будет готов, он будет скомпилирован на всех архитектурах, и он не будет изменён в течении некоторого времени. Тогда он становится кандидатом для включения в тестируемый дистрибутив; группа пакетов нестабильного выпуска выбирается в зависимости от ряда количественных критериев. Каждый день программа автоматически выбирает пакеты для включения в тестируемый выпуск в соответствии с правилами, гарантирующими определенный уровень качества:

Эта система явно не является идеальной; критические ошибки регулярно встречаются в пакетах, включенных в Testing. Тем не менее это, как правило, эффективно, и Testing создает гораздо меньше проблем, чем Unstable, что для многих является хорошим компромиссом между стабильностью и новизной.

Let us suppose that our package is now included in Testing. As long as it has room for improvement, its maintainer must continue to improve it and restart the process from Unstable (but its later inclusion in Testing is generally faster: unless it changed significantly, all of its dependencies are already available). When it reaches perfection, the maintainer has completed their work. The next step is the inclusion in the Stable distribution, which is, in reality, a simple copy of Testing at a moment chosen by the Release Manager. Ideally, this decision is made when the installer is ready, and when no program in Testing has any known critical bugs.

Поскольку этот момент никогда не настаёт, на практике Debian ищет компромисс: удалить пакеты, сопровождающий которых не смог исправить ошибки вовремя, либо согласиться выпустить дистрибутив с ошибками в тысячах программ. Менеджер выпуска заранее сообщает о периоде заморозки, в ходе которого каждое обновление тестируемого выпуска должно быть одобрено. Цель заморозки заключается в предотвращении добавления новых версий пакета (и новых ошибок) и разрешении только тех обновлений, которые исправляют существующие ошибки.

After the release of a new stable version, the Stable Release Managers manage all further development (called “revisions”, ex: 10.1, 10.2, 10.3 for version 10). These updates systematically include all security patches. They will also include the most important corrections (the maintainer of a package must prove the gravity of the problem that they wish to correct in order to have their updates included).

At the end of the journey, our hypothetical package is now included in the stable distribution. This journey, not without its difficulties, explains the significant delays separating the Debian Stable releases. This contributes, over all, to its reputation for quality. Furthermore, the majority of users are satisfied using one of the three distributions simultaneously available. The system administrators, concerned above all about the stability of their servers, don't need the latest and greatest version of GNOME; they can choose Debian Stable, and they will be satisfied. End users, more interested in the latest versions of GNOME or KDE Plasma than in rock-solid stability, will find Debian Testing to be a good compromise between a lack of serious problems and relatively up-to-date software. Finally, developers and more experienced users may blaze the trail, testing all the latest developments in Debian Unstable right out of the gate, at the risk of suffering the headaches and bugs inherent in any new version of a program. To each their own Debian!

Каждый стабильный релиз (Stable) имеет ожидаемое время жизни около 5 лет и, учитывая, что релизы, как правило, выходят каждые 2 года, может быть до 3 поддерживаемых релизов в определенный момент времени. При выходе нового стабильного релиза предыдущий релиз становится Oldstable, а прежний Oldstable становится Oldoldstable.

Долгосрочная поддержка (LTS) выпусков Debian - недавняя инициатива: отдельные разработчики и компании объединили свои усилия для создания команды Debian LTS. Целью новой команды является поддержка старых релизов, которые больше не поддерживаются командой безопасности Debian.

The Debian security team handles security support in the current Stable release and also in the Oldstable release (but only for as long as is needed to ensure one year of overlap with the current stable release). This amounts roughly to three years of support for each release. The Debian LTS team handles the last (two) years of security support so that each release benefits from at least 5 years of support and so that users can upgrade from version N to N+2, for example, from Debian 9 Stretch to Debian 11 Bullseye.