То, что вы заявляете, не относится ко всему семейству дистрибутивов с постепенным выпуском
Для программного обеспечения для обслуживания системы гораздо сложнее разрешить проблемы совместимости между пакетами при обновлении только некоторых частей системы или поддержании согласованности конфигурации в течение всех обновлений. Различные пакеты программного обеспечения должны быть адаптированы для работы друг с другом.
Вот почему самое простое (то есть самое надежное и в то же время затраченное на разработку ) решение для предоставления обновления системы - это периодически готовить полный, полностью протестированный, полностью инсталляционный выпуск. Корпоративные решения, такие как Red Hat, занимают позицию, согласно которой клиенту должна быть предоставлена надежная система, и он должен быть обеспокоен, ломая обновления как можно дольше. (Конечно, незначительные обновления и исправления должны быть доступны или даже автоматически обновляться). Это также общая философия бесплатных серверных дистрибутивов, таких как CentOS.
Предоставление конечному пользователю бесшовного маршрута обновления между выпусками является большой проблемой для разработчиков системы. Многие дистрибутивы предпочитают не жертвовать своим скудным временем ради этого. Многие популярные пакеты (например, QT) сложно обновить, часто требуя полной переустановки. Что еще более важно, многие проекты демонстрируют снижение усилий по разработке или вытесняются новыми технологиями. В случае системных пакетов это часто требует значительного изменения системы. Процедуры миграции могут быть особенно сложными для реализации, если они должны учитывать тот факт, что некоторые люди захотят перейти с версии C на D, а другие будут переключаться с формы B или с A или из какого-то пользовательского состояния в середине.
Итак, как вы уже могли догадаться, самый сложный подход - это скользящий релиз. Я не знаю деталей подхода Debian, но из вашего описания я вижу, что они где-то посередине.