Product SiteDocumentation Site

1.6. دورة حياة الإصدار

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

1.6.1. الحالة التجريبية

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

1.6.2. الحالة غير المستقرة

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. 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.
ترجمة الحزم باستخدام البانيات الآلية

شكل 1.2. ترجمة الحزم باستخدام البانيات الآلية

1.6.3. الهجرة إلى الاختبارية

بعد مدة، تنضج الحزمة؛ وتترجم على جميع المعماريات، كما لن تجرى عليها أي تعديلات جديدة لفترة من الزمن. عندئذ تُرشَّح للتضمين في التوزيعة الاختبارية (Testing) — وهي مجموعة من الحزم غير المستقرة المختارة وفقاً لمعايير محددة. كل يوم يختار برنامج آلي الحزم التي ستضاف إلى الاختبارية، حسب مجموعة من العناصر التي تضمن مستوى معين من الجودة:
  1. عدم وجود علل حرجة، أو على الأقل، أن تكون العلل الحرجة أقل مما هي في النسخة الموجودة حالياً في الاختبارية؛
  2. at least 5 days spent in Unstable, which is usually sufficient time to find and report any serious problems (successfully passing the package's own test suite, if it has one, reduces that time);
  3. نجاح ترجمة الحزمة على جميع المعماريات المدعومة رسمياً؛
  4. dependencies that can be satisfied in Testing, or that can at least be moved there together with the package in question;
  5. automatic quality tests of the package (autopkgtest) — if defined — don't show any regression.
من الواضح أن هذا النظام ليس معصوماً عن الخطأ؛ فالعلل الحرجة تظهر بانتظام في الحزم المضمنة في الاختبارية. مع ذلك، فهو فعال عموماً، والمشاكل التي تبرز في الاختبارية أقل بكثير من التي تجدها في غير المستقرة، وبذلك تكون للعديد من الأشخاص حلاً وسطاً مقبولاً بين الاستقرار والحداثة.

1.6.4. الترقية من الاختبارية إلى المستقرة

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

شكل 1.3. مسار الحزمة بين نسخ دبيان المختلفة

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!
المسار الزمني للبرامج التي تحزمها دبيان

شكل 1.4. المسار الزمني للبرامج التي تحزمها دبيان

1.6.5. حالة النسخة المستقرة القديمة والمستقرة سابقة القديمة

لكل نسخة مستقرة عمر يقدر بحوالي 5 سنوات، وبما أن الإصدارات الجديدة تظهر كل سنتين فمن الممكن أن تبقى 3 إصدارات مدعومة متاحة في أي لحظة زمنية. عندما تصدر نسخة مستقرة جديدة، تصبح النسخة السابقة لها مستقرة قديمة وسابقتها الأقدم تصبح المستقرة سابقة القديمة.
إصدارات دبيان طويلة الدعم هذه هي مبادرة حديثة العهد: تضامن المساهمون الأفراد والشركات لتكوين فريق دبيان LTS (اختصار Long Term Support). يتولى هذا الفريق مسؤولية دعم الإصدارات الأقدم التي يتوقف فريق دبيان security عن دعمها.
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, for example from Debian 8 "Jessie" to Debian 10 "Buster".