دعنا في البداية نلقي نظرة على على الحالة الخاصة للتوزيعة Experimental (التجريبية): هذه عبارة عن مجموعة من حزم دبيان التي تحوي برمجيات قيد التطوير، ولا يشترط أن تكون مكتملة، من هنا جاء الاسم. لا يستطيع كل شيء عبور هذه المرحلة؛ يضيف بعض المطورين هنا للحصول على ملاحظات من المستخدمين الأكثر خبرة (أو المستخدمين الشجعان).

فيما عدا ذلك، تستضيف هذه التوزيعة بين الحين والآخر التعديلات المهمة على الحزم الأساسية، التي سينتج عن إضافتها إلى غير المستقرة آثار خطيرة إذا وجدت فيها علل قاتلة. لذلك تعزل هذه التوزيعة بالكامل، ولا تهاجر حزمها أبداً إلى النسخ الأخرى (إلا عن طريق تدخل المشرف أو ftpmasters بشكل واضح ومباشر). كما أنها ليست مستقلة بذاتها: فلا تحوي إلا مجموعة فرعية من الحزم، وهي لا تشمل النظام الأساسي عموماً. إذن، لا تفيد التوزيعة التجريبية إلا إذا جُمِعَت مع توزيعة أخرى مستقلة، مثل غير المستقرة.

دعنا نلتفت إلى حالة الحزم النموذجية. يُنشِئ المشرف حزمة أولية، التي يترجمها للنسخة Unstable (غير المستقرة) من دبيان ويضعها على مخدم ftp-master.debian.org. هذا الحدث الأولي يستدعي تدقيق ومصادقة ftmasters. بعدها يصبح البرنامج متاحاً في التوزيعة غير المستقرة، وهي التوزيعة الأحدث التي يختارها المستخدمون الذين يهتمون بالحصول على أحدث الحزم أكثر مما تهمهم العلل الخطيرة. يكتشف هؤلاء البرنامج إذاً ويختبرونه.

إذا واجهتهم مشاكل، سوف يبلغون عنها إلى مشرف الحزمة. بعدها يحضر المشرف نسخاً مصححة بانتظام، التي يرفعها إلى المخدم.

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) — وهي مجموعة من الحزم غير المستقرة المختارة وفقاً لمعايير محددة. كل يوم يختار برنامج آلي الحزم التي ستضاف إلى الاختبارية، حسب مجموعة من العناصر التي تضمن مستوى معين من الجودة:

من الواضح أن هذا النظام ليس معصوماً عن الخطأ؛ فالعلل الحرجة تظهر بانتظام في الحزم المضمنة في الاختبارية. مع ذلك، فهو فعال عموماً، والمشاكل التي تبرز في الاختبارية أقل بكثير من التي تجدها في غير المستقرة، وبذلك تكون للعديد من الأشخاص حلاً وسطاً مقبولاً بين الاستقرار والحداثة.

دعنا نفترض أن حزمتنا وصلت الآن إلى الاختبارية. طالما أن هناك مجال للتحسين، يجب أن يتابع المشرف على الحزمة تحسينها وإعادة بدء العملية من غير المستقرة (لكن إضافتها لاحقاً إلى الاختبارية تكون أسرع عموماً: فإذا لم تتغير بشكل كبير، ستكون كل اعتمادياتها موجودة مسبقاً). عندما تصل إلى المثالية، ينتهي عمل المشرف. الخطوة التالية، هي تضمينها في التوزيعة المستقرة (Stable)، وما هي ‒في الواقع‒ إلا نسخة بسيطة من الاختبارية في لحظة محددة يختارها مديرو الإصدار. في الحالة المثالية، يُتَّخذ هذا القرار عند جاهزية المُثبِّت، وعندما لا يحوي أي برنامج في الاختبارية أي علل حرجة.

بما أن هذه اللحظة لن تصل أبداً في الحقيقة، يجب أن يضحي دبيان عملياً: إما بإزالة الحزم التي لا يتمكن مشرفوها من تصحيح عللها في الوقت المناسب، أو الاتفاق على إصدار توزيعة تحوي بعض العلل من بين آلاف البرامج. يعلن مديرو الإصدار قبل هذا عن فترة تجميد، تحتاج أثناءها كل التحديثات التي تصل إلى الاختبارية للموافقة. الهدف هنا منع دخول أي نسخة جديدة (مع عللها الجديدة)، وقبول التحديثات التي تصحح العلل السابقة فقط.

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!

لكل نسخة مستقرة عمر يقدر بحوالي 5 سنوات، وبما أن الإصدارات الجديدة تظهر كل سنتين فمن الممكن أن تبقى 3 إصدارات مدعومة متاحة في أي لحظة زمنية. عندما تصدر نسخة مستقرة جديدة، تصبح النسخة السابقة لها مستقرة قديمة وسابقتها الأقدم تصبح المستقرة سابقة القديمة.

إصدارات دبيان طويلة الدعم هذه هي مبادرة حديثة العهد: تضامن المساهمون الأفراد والشركات لتكوين فريق دبيان LTS (اختصار Long Term Support). يتولى هذا الفريق مسؤولية دعم الإصدارات الأقدم التي يتوقف فريق دبيان security عن دعمها.

يتولى فريق Debian security دعم النسخة المستقرة الحالية وأيضاً النسخة المستقرة القديمة (ولكن الدعم يستمر فقط بحيث يضمن تداخل النسخة القديمة لسنة واحدة مع المستقرة الحالية). هذا يعطي حوالي ثلاث سنوات من الدعم لكل إصدار. يتولى فريق Debian LTS الدعم الأمني في آخر سنتين (تقريباً) بحيث تستفيد كل نسخة من دعم لا يقل عن 5 سنوات وبحيث يتمكن المستخدمون من الترقية من النسخة N إلى N+2.