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

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

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

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

Каждый обновлённый пакет в течение шести часов обновляется на всех зеркалах Debian по всему миру. Пользователи тестируют исправления и ищут другие проблемы, которые могли возникнуть из-за этих изменений. Часто могут производиться несколько обновлений. В такие моменты на помощь приходят роботы автоматической сборки. Чаще всего сопровождающий имеет в своём распоряжении один обычный ПК и компилирует свои пакеты на архитектуре amd64 (или i386); узлы автоматической сборки автоматически компилируют версии для всех остальных архитектур. Некоторые процессы компиляции могут завершиться неудачно; в этом случае сопровождающий получит отчёт об ошибке с указанием проблемы, которую следует исправить в будущих версиях пакета. В случае обнаружения ошибки специалистом по некоторой данной архитектуре, отчёт об ошибке может содержать в себе готовый к использованию патч.

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

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

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

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

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

В конце путешествия наш гипотетический пакет входит в состав стабильного дистрибутива. Этот путь, который не так-то прост, объясняет значительные задержки, разделяющие стабильные выпуски Debian. Это способствует укреплению репутации с упором на качество. Кроме того, большинство пользователей устраивает использование одного из трёх поддерживаемых дистрибутивов, доступных одновременно. Системные администраторы, прежде всего, обеспокоены стабильностью своих серверов, они не нуждаются в новейшей версии GNOME; они могут выбрать стабильный выпуск Debian, и они будут удовлетворены его стабильностью. Конечные пользователи, напротив, больше заинтересованы в самых свежих версиях GNOME или KDE Plasma, а не в стабильности, они могут найти это в тестируемом выпуске Debian, который будет хорошим компромиссом между отсутствием серьезных проблем и относительной актуальностью ПО. Наконец, разработчики и более опытные пользователи могут прокладывать путь, тестируя все последние разработки в нестабильном выпуске Debian, рискуя получить головную боль и ошибки, присущие любой новой версии программы. Для каждого есть свой собственный Debian!

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

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

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