يحوي المشروع ثلاث أو أربع نسخ مختلفة من كل برنامج في الوقت نفسه، تسمى تجريبية، غير مستقرة، اختبارية، ومستقرة. كل واحدة توافق مرحلة مختلفة من التطوير. لفهم الوضع بشكل جيد، دعنا نلقي نظرة على رحلة البرنامج، منذ التحزيم الأولي حتى إضافته إلى النسخة المستقرة من دبيان.
دعنا في البداية نلقي نظرة على على الحالة الخاصة للتوزيعة Experimental (التجريبية): هذه عبارة عن مجموعة من حزم دبيان التي تحوي برمجيات قيد التطوير، ولا يشترط أن تكون مكتملة، من هنا جاء الاسم. لا يستطيع كل شيء عبور هذه المرحلة؛ يضيف بعض المطورين هنا للحصول على ملاحظات من المستخدمين الأكثر خبرة (أو المستخدمين الشجعان).
فيما عدا ذلك، تستضيف هذه التوزيعة بين الحين والآخر التعديلات المهمة على الحزم الأساسية، التي سينتج عن إضافتها إلى غير المستقرة آثار خطيرة إذا وجدت فيها علل قاتلة. لذلك تعزل هذه التوزيعة بالكامل، ولا تهاجر حزمها أبداً إلى النسخ الأخرى (إلا عن طريق تدخل المشرف أو ftpmasters بشكل واضح ومباشر). كما أنها ليست مستقلة بذاتها: فلا تحوي إلا مجموعة فرعية من الحزم، وهي لا تشمل النظام الأساسي عموماً. إذن، لا تفيد التوزيعة التجريبية إلا إذا جُمِعَت مع توزيعة أخرى مستقلة، مثل غير المستقرة.
1.6.2. الحالة غير المستقرة
دعنا نلتفت إلى حالة الحزم النموذجية. يُنشِئ المشرف حزمة أولية، التي يترجمها للنسخة Unstable (غير المستقرة) من دبيان ويضعها على مخدم ftp-master.debian.org
. هذا الحدث الأولي يستدعي تدقيق ومصادقة ftmasters. بعدها يصبح البرنامج متاحاً في التوزيعة غير المستقرة، وهي التوزيعة الأحدث التي يختارها المستخدمون الذين يهتمون بالحصول على أحدث الحزم أكثر مما تهمهم العلل الخطيرة. يكتشف هؤلاء البرنامج إذاً ويختبرونه.
إذا واجهتهم مشاكل، سوف يبلغون عنها إلى مشرف الحزمة. بعدها يحضر المشرف نسخاً مصححة بانتظام، التي يرفعها إلى المخدم.
كل تحديث جديد للحزمة ينتقل لجميع مرايا دبيان حول العالم خلال ست ساعات. بعدها يستطيع المستخدمون اختبار التصحيحات والبحث عن أي مشاكل أخرى نتجت عن التعديلات. قد تجري بعدها تحديثات عديدة سريعة. خلال هذه الفترة، تنطلق روبوتات البناء الآلي (autobuilder) للعمل. في أغلب الأحيان، يملك المشرف حاسوباً شخصياً تقليدياً وحيداً ويترجم حزمته على المعمارية amd64 (أو i386)؛ تتولى البانيات الآلية (autobuilders) العمل وتترجم نسخاً لجميع المعماريات الأخرى آلياً. قد تفشل بعض الترجمات؛ عندها سيستقبل المشرف تقرير علة يوضّح المشكلة، التي تصحح لاحقاً في النسخ التالية. أما إذا اكتشف العلة أحد الخبراء في المعمارية المذكورة، فقد يرفق رقعة جاهزة للاستخدام بتقرير العلة.
1.6.3. الهجرة إلى الاختبارية
بعد مدة، تنضج الحزمة؛ وتترجم على جميع المعماريات، كما لن تجرى عليها أي تعديلات جديدة لفترة من الزمن. عندئذ تُرشَّح للتضمين في التوزيعة الاختبارية (Testing) — وهي مجموعة من الحزم غير المستقرة المختارة وفقاً لمعايير محددة. كل يوم يختار برنامج آلي الحزم التي ستضاف إلى الاختبارية، حسب مجموعة من العناصر التي تضمن مستوى معين من الجودة:
عدم وجود علل حرجة، أو على الأقل، أن تكون العلل الحرجة أقل مما هي في النسخة الموجودة حالياً في الاختبارية؛
قضاء 10 أيام على الأقل في غير المستقرة، وهذه فترة كافية للعثور على أي مشاكل خطيرة والإبلاغ عنها؛
نجاح ترجمة الحزمة على جميع المعماريات المدعومة رسمياً؛
يجب أن تكون اعتماديات الحزمة قابلة للحل في الاختبارية، أو أن يمكن على الأقل نقل اعتمادياتها معها.
من الواضح أن هذا النظام ليس معصوماً عن الخطأ؛ فالعلل الحرجة تظهر بانتظام في الحزم المضمنة في الاختبارية. مع ذلك، فهو فعال عموماً، والمشاكل التي تبرز في الاختبارية أقل بكثير من التي تجدها في غير المستقرة، وبذلك تكون للعديد من الأشخاص حلاً وسطاً مقبولاً بين الاستقرار والحداثة.
1.6.4. الترقية من الاختبارية إلى المستقرة
دعنا نفترض أن حزمتنا وصلت الآن إلى الاختبارية. طالما أن هناك مجال للتحسين، يجب أن يتابع المشرف على الحزمة تحسينها وإعادة بدء العملية من غير المستقرة (لكن إضافتها لاحقاً إلى الاختبارية تكون أسرع عموماً: فإذا لم تتغير بشكل كبير، ستكون كل اعتمادياتها موجودة مسبقاً). عندما تصل إلى المثالية، ينتهي عمل المشرف. الخطوة التالية، هي تضمينها في التوزيعة المستقرة (Stable)، وما هي ‒في الواقع‒ إلا نسخة بسيطة من الاختبارية في لحظة محددة يختارها مديرو الإصدار. في الحالة المثالية، يُتَّخذ هذا القرار عند جاهزية المُثبِّت، وعندما لا يحوي أي برنامج في الاختبارية أي علل حرجة.
بما أن هذه اللحظة لن تصل أبداً في الحقيقة، يجب أن يضحي دبيان عملياً: إما بإزالة الحزم التي لا يتمكن مشرفوها من تصحيح عللها في الوقت المناسب، أو الاتفاق على إصدار توزيعة تحوي بعض العلل من بين آلاف البرامج. يعلن مديرو الإصدار قبل هذا عن فترة تجميد، تحتاج أثناءها كل التحديثات التي تصل إلى الاختبارية للموافقة. الهدف هنا منع دخول أي نسخة جديدة (مع عللها الجديدة)، وقبول التحديثات التي تصحح العلل السابقة فقط.
After the release of a new stable version, the Stable Release Manager manages all further development (called “revisions”, ex: 5.0.1, 5.0.2, 5.0.3 for version 5.0). 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).
في نهاية الرحلة، أصبحت حزمتنا المفترضة في التوزيعة المستقرة. توضح هذه الرحلة، التي لا تخلو من الصعوبات، التأخيرات الكبيرة التي تفصل إصدارات دبيان المستقرة. يساهم هذا إجمالاً في سمعة دبيان بمجال الجودة. بالإضافة لذلك، غالبية المستخدمين يرضون باستخدام إحدى التوزيعات الثلاث المتوفرة في كل الأوقات. فمديري النظم، الذين تهمهم استقرارية مخدماتهم أكثر من أي شيء، لا يحتاجون آخر صيحات النسخة الحديثة من GNOME؛ يستطيعون اختيار دبيان المستقرة، وسيكونون راضين. أما المستخدمون النهائيون، الذين تهمهم إصدارات GNOME أو KDE الأخيرة بدلاً من الاستقرارية التي لا تهتز، سيجدون دبيان الاختبارية حلاً وسطاً مقبولاً بين الحصول على أحدث البرمجيات وبين عدم وجود مشاكل كبيرة. أخيراً، المطورون والمستخدمون الأكثر خبرة يستطيعون تمهيد الطريق عبر اختبار أحدث التطورات في دبيان غير المستقرة في منبعها، على حساب أوجاع الرأس وملاقاة العلل التي تظهر في كل النسخ الجديدة من البرامج. لكل واحد دبيان خاص به!