در ابتدا بیایید به مورد خاص توزیع آزمایشی نگاهی بیندازیم: این گروهی است از بسته‌های دبیان که شامل نرم‌افزارهای در حال توسعه هستند، نه آن‌هایی که کامل شده‌اند، همانطور که از نامش مشخص است. هر نرم‌افزاری از این مرحله عبور نمی‌کند؛ برخی توسعه‌دهندگان بسته‌های خود را در اینجا قرار می‌دهند تا از سایر کاربران باتجربه (یا شجاع‌تر) دیدگاهشان را جویا شوند.

در غیر اینصورت، این توزیع به صورت عمده شامل تغییرات مهمی در بسته‌های پایه است که یکپارچه‌سازی آن‌ها در ناپایدار با باگ‌های جدی می‌تواند تاثیرات مخربی به همراه داشته باشد. بنابراین، یک توزیع کاملاً ایزوله به حساب می‌آید، بسته‌های آن هیچگاه به نسخه‌های دیگر مهاجرت نمی‌کنند (مگر تحت نظارت توسعه‌دهنده اصلی یا ftpmasters). همچنین یک محیط جداگانه نیز به حساب نمی‌آید: تنها قسمتی از بسته‌های موجود در توزیع آزمایشی حاضر هستند و شامل سیستم پایه دبیان نمی‌باشد. این توزیع در مقایسه با یک توزیع جداگانه دیگر مانند ناپایدار معنا پیدا می‌کند.

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.

اندکی بعد، بسته به بلوغ نسبی می‌رسد؛ روی تمام معماری‌ها کامپایل می‌شود و شامل تغییرات بجای مانده نخواهد بود. اینجاست که برای قرار گرفتن در توزیع تحت‌آزمون به عنوان کاندید انتخاب می‌شود - گروهی از بسته‌های ناپایدار که بر اساس شرایط کیفی خاصی انتخاب شده‌اند. هر روزه یک برنامه به صورت خودکار بسته‌های مورد نیاز برای قرار گرفتن در شاخه تحت‌آزمون را انتخاب می‌کند، بر اساس عنصرهایی که سطح خاصی از کیفیت برنامه را تضمین می‌نمایند:

این سیستم مشخصاً بدون خطا نخواهد بود؛ باگ‌های اساسی معمولاً در بسته‌های موجود در شاخه تحت‌آزمون پیدا می‌شوند. هنوز، شاخه تحت‌آزمون نسبت به ناپایدار مشکلات کمتری ایجاد می‌نماید که برای بسیاری مقایسه مناسبی بین پایداری و تازگی به حساب می‌آید.

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.

از آنجا که این لحظه هیچگاه به حقیقت نمی‌پیوندد، در عمل دبیان باید با آن سازش کند: حذف بسته‌هایی که مسئول آن در زمان مقرر نتوانسته است مشکلات موجود را رفع کند یا توافق با انتشار توزیعی که شامل هزاران باگ در برنامه‌هایش است. مدیر انتشار قبل از این یک بازه زمانی ثابت شده را در نظر گرفته است، که در طی آن هر بروزرسانی برای شاخه تحت‌آزمون باید پذیرفته شود. هدف از اینکار پیشگیری از نسخه جدید و باگ‌های مربوط به آن است، و تنها پذیرش بروزرسانی‌هایی که منجر به رفع باگ‌ها می‌گردند.

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!

هر نسخه پایدار شامل چرخه حیاتی تقریباً ۵ ساله است و امکان انتشار نسخه‌های جدید هر ۲ سال یکبار را فراهم می‌آورد، در هر دوره زمانی تنها ۳ انتشار قابل پشتیبانی وجود خواهند داشت. زمانی که یک انتشار پایدار جدید اتفاق می‌افتد، نسخه پیشین به پایدار سابق و نسخه قبل از آن به پایدار قدیم تغییر نام می‌دهد.

پشتیبانی بلند مدت (LTS) دبیان یک رویکرد جدید در پروژه به حساب می‌آید: مشارکت‌کنندگان انفرادی و شرکت‌های گوناگون به یکدیکر پیوستند تا تیم LTS دبیان را تشکیل دهند. نسخه‌های قدیمی‌تر که دیگر تحت حمایت تیم امنیتی دبیان قرار ندارند به این تیم جدید واگذار می‌گردند.

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.