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

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

Давайте вернёмся обратно к случаю типичного пакета. Сопровождающий создает первоначальный пакет, который он компилирует для Unstable версии и помещает на сервер ftp-master.debian.org. Это первое событие включает в себя инспекции и проверки от ftpmasters. Затем программное обеспечение доступно в дистрибутиве Unstable, который является передовым дистрибутивом, за что его и выбирают пользователи для которых более важно иметь свежие пакеты, нежели наличие серьёзных ошибок. Они тестируют программы.

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

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. Most frequently, the maintainer has only one traditional PC and has compiled their package on the amd64 (or i386) architecture (or they opted for a source-only upload, thus without any precompiled package); the autobuilders take over and automatically compile versions for all the other 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, что для многих является хорошим компромиссом между стабильностью и новизной.

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

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

After the release of a new stable version, the Stable Release Managers manage all further development (called “revisions”, ex: 7.1, 7.2, 7.3 for version 7). 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.

Команда безопасности Debian осуществляет поддержку безопасности в текущем стабильном релизе Stable и также в старом стабильном релизе Oldstable (в течении одного года после выпуска текущего стабильного релиза). Это примерно три года поддержки для каждого выпуска. Команда Debian LTS осуществляет поддержку безопасности в течении двух лет после выпуска текущего стабильного релиза, таким образом каждый релиз имеет как минимум пятилетнюю поддержку и поэтому пользователи могут обновляться с версии N до N+2.