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

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

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

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

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

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

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

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

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

После выпуска новой стабильной версии, менеджер стабильного релиза управляет всей дальнейшей разработкой (это «ревизии», например, 10.1, 10.2, 10.3 для версии 10). Эти систематические обновления включают в себя все исправления безопасности. Они также включают наиболее важные исправления (сопровождающий пакета должен доказать серьезность проблемы, которую он хотел бы исправить, прежде чем обновления могут быть включены в ревизию).

В конце путешествия наш гипотетический пакет входит в состав стабильного дистрибутива. Этот путь, который не так-то прост, объясняет значительные задержки, разделяющие стабильные выпуски 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.