The project will simultaneously have three to six different versions of each program, named Experimental, Unstable, Testing, Stable, Oldstable, and even Oldoldstable. Each one corresponds to a different phase in development. For a good understanding, let us take a look at a program's journey, from its initial packaging to inclusion in a stable version of Debian.
دعنا في البداية نلقي نظرة على على الحالة الخاصة للتوزيعة Experimental (التجريبية): هذه عبارة عن مجموعة من حزم دبيان التي تحوي برمجيات قيد التطوير، ولا يشترط أن تكون مكتملة، من هنا جاء الاسم. لا يستطيع كل شيء عبور هذه المرحلة؛ يضيف بعض المطورين هنا للحصول على ملاحظات من المستخدمين الأكثر خبرة (أو المستخدمين الشجعان).
فيما عدا ذلك، تستضيف هذه التوزيعة بين الحين والآخر التعديلات المهمة على الحزم الأساسية، التي سينتج عن إضافتها إلى غير المستقرة آثار خطيرة إذا وجدت فيها علل قاتلة. لذلك تعزل هذه التوزيعة بالكامل، ولا تهاجر حزمها أبداً إلى النسخ الأخرى (إلا عن طريق تدخل المشرف أو ftpmasters بشكل واضح ومباشر). كما أنها ليست مستقلة بذاتها: فلا تحوي إلا مجموعة فرعية من الحزم، وهي لا تشمل النظام الأساسي عموماً. إذن، لا تفيد التوزيعة التجريبية إلا إذا جُمِعَت مع توزيعة أخرى مستقلة، مثل غير المستقرة.
1.6.2. الحالة غير المستقرة
دعنا نلتفت إلى حالة الحزم النموذجية. يُنشِئ المشرف حزمة أولية، التي يترجمها للنسخة 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; 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.
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: 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).
في نهاية الرحلة، أصبحت حزمتنا المفترضة في التوزيعة المستقرة. توضح هذه الرحلة، التي لا تخلو من الصعوبات، التأخيرات الكبيرة التي تفصل إصدارات دبيان المستقرة. يساهم هذا إجمالاً في سمعة دبيان بمجال الجودة. بالإضافة لذلك، غالبية المستخدمين يرضون باستخدام إحدى التوزيعات الثلاث المتوفرة في كل الأوقات. فمديري النظم، الذين تهمهم استقرارية مخدماتهم أكثر من أي شيء، لا يحتاجون آخر صيحات النسخة الحديثة من GNOME؛ يستطيعون اختيار دبيان المستقرة، وسيكونون راضين. أما المستخدمون النهائيون، الذين تهمهم إصدارات GNOME أو KDE الأخيرة بدلاً من الاستقرارية التي لا تهتز، سيجدون دبيان الاختبارية حلاً وسطاً مقبولاً بين الحصول على أحدث البرمجيات وبين عدم وجود مشاكل كبيرة. أخيراً، المطورون والمستخدمون الأكثر خبرة يستطيعون تمهيد الطريق عبر اختبار أحدث التطورات في دبيان غير المستقرة في منبعها، على حساب أوجاع الرأس وملاقاة العلل التي تظهر في كل النسخ الجديدة من البرامج. لكل واحد دبيان خاص به!
1.6.5. The Oldstable and Oldoldstable Status
Each Stable release has an expected lifetime of about 5 years and given that releases tend to happen every 2 years, there can be up to 3 supported releases at a given point of time. When a new stable release happens, the former release becomes Oldstable and the one even before becomes Oldoldstable.
This Long Term Support (LTS) of Debian releases is a recent initiative: individual contributors and companies joined forces to create the Debian LTS team. Older releases which are no longer supported by the Debian security team fall under the responsibility of this new team.
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 releases benefits from at least 5 years of support and so that users can upgrade from version N to N+2.