Product SiteDocumentation Site

1.6. چرخه‌حیات یک انتشار

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

1.6.1. وضعیت شاخه آزمایشی

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

1.6.2. وضعیت شاخه ناپایدار

بیایید به وضعیت یک بسته معمولی باز گردیم. فرد مسئول آن، یک بسته اولیه ایجاد می‌کند که برای نسخه ناپایدار کامپایل می‌شود و روی سرور ftp-master.debian.org قرار می‌گیرد. اولین رویداد، شناسایی و اعتبارسنجی بسته از طرف ftpmasters خواهد بود. سپس نرم‌افزار در توزیع ناپایدار قرار می‌گیرد که توزیع “محبوب” کاربرانی است که علاقه دارند از آخرین قابلیت‌های نرم‌افزار بدون نگرانی از باگ‌های جدی استفاده نمایند. آن‌ها برنامه را پیدا کرده و اقدام به تست (آزمون) آن می‌نمایند.
اگر در این مرحله باگی پیدا کنند، آن را به مسئول بسته گزارش می‌کنند. مسئول بسته آنگاه نسخه‌های بروزتری ارائه می‌دهد، که آن‌ها در سرور اصلی آپلود می‌کنند.
هر بسته جدیدی که بروزرسانی گردد، ظرف مدت شش ساعت در تمام سرورهای دبیان بروزرسانی می‌شود. آنگاه کاربران به بررسی اصلاحات پرداخته و مشکلاتی که ممکن است با تغییرات اخیر بوجود آمده باشد. چندین بروزرسانی ممکن است به سرعت رخ دهند. در این زمان، ربات‌های autobuilder دست بکار می‌شوند. در اکثر اوقات، مسئول بسته تنها یک رایانه رومیزی دارد که از بسته خود را برای معماری‌های amd64 (یا i386) کامپایل می‌کند؛ autobuilder در اینجا اقدام به کامپایل بسته برای سایر معماری‌ها می‌نماید. برخی از این کامپایل‌ها ممکن است ناموفق باشد؛ فرد مسئول در این گام گزارش باگ را دریافت کرده تا در نسخه بعدی برطرف نماید. زمانی که این باگ برای یک متخصص در معماری مورد نظر شناسایی شود، گزارش آن به همراه فایل پچ مورد استفاده ارائه می‌شود.
فرآیند کامپایل بسته‌ها توسط autobuilder

شكل 1.2. فرآیند کامپایل بسته‌ها توسط autobuilder

1.6.3. مهاجرت به شاخه تحت آزمون

اندکی بعد، بسته به بلوغ نسبی می‌رسد؛ روی تمام معماری‌ها کامپایل می‌شود و شامل تغییرات بجای مانده نخواهد بود. اینجاست که برای قرار گرفتن در توزیع تحت‌آزمون به عنوان کاندید انتخاب می‌شود - گروهی از بسته‌های ناپایدار که بر اساس شرایط کیفی خاصی انتخاب شده‌اند. هر روزه یک برنامه به صورت خودکار بسته‌های مورد نیاز برای قرار گرفتن در شاخه تحت‌آزمون را انتخاب می‌کند، بر اساس عنصرهایی که سطح خاصی از کیفیت برنامه را تضمین می‌نمایند:
  1. عدم وجود باگ‌های اساسی، یا حداقل کمتر از تعدادی که در نسخه موجود در شاخه تحت‌آزمون قرار دارد؛
  2. گذشتن حداقل ۱۰ روز از بودن در شاخه ناپایدار، که زمان کافی برای گزارش مشکلات جدی فراهم می‌آورد؛
  3. کامپایل موفقیت‌آمیز در تمام معماری‌های تحت پوشش؛
  4. وابستگی‌هایی که می‌توانند در شاخه تحت‌آزمون برطرف گردند، یا حداقل می‌توانند به همراه بسته مورد نظر به آنجا انتقال یابند.
این سیستم مشخصاً بدون خطا نخواهد بود؛ باگ‌های اساسی معمولاً در بسته‌های موجود در شاخه تحت‌آزمون پیدا می‌شوند. هنوز، شاخه تحت‌آزمون نسبت به ناپایدار مشکلات کمتری ایجاد می‌نماید که برای بسیاری مقایسه مناسبی بین پایداری و تازگی به حساب می‌آید.

1.6.4. ارتقاء از شاخه تحت‌آزمون به پایدار

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

شكل 1.3. مسیر یک بسته در میان نسخه‌های گوناگون دبیان

پس از انتشار یک نسخه جدید پایدار، مدیر نسخه پایدار تمام توسعه‌های پیش رو را مدیریت می‌کند (که با نام “revision” شناخته می‌شوند مانند: ۷.۱، ۷.۲، ۷.۳ برای نسخه ۷). این بروزرسانی‌ها به طور ساختاریافته‌ای شامل پچ‌های امنیتی نیز می‌باشند. آن‌ها همچنین مهم‌ترین اصلاحات هر بسته را نیز شامل می‌شوند (مسئول هر بسته باید مشکل مورد نظر را تایید کرده قبل از اینکه بروزرسانی‌های ممکن روی آن صورت پذیرد).
در پایان این سفر، بسته فرضی ما در توزیع پایدار قرار گرفته است. این سفر، که البته بدون مشکل نیز نمی‌باشد، تاخیر موجود بین نسخه‌های پایدار دبیان را توضیح می‌دهد. این عملیات است که به اعتبار کیفی پروژه ارزش می‌بخشد. علاوه بر این، طیف گسترده‌ای از کاربران در استفاده همزمان یکی از سه توزیع موجود، رضایت دارند. مدیر سیستم‌هایی که دغدغه پایداری نرم‌افزار سرور را دارند، به آخرین و بهترین نسخه از میزکار گنوم نیازی ندارند؛ آن‌ها می‌توانند توزیع پایدار دبیان را انتخاب کرده و از آن لذت ببرند. کاربران نهایی، که به آخرین نسخه از میزکارهای گنوم یا کی‌دی‌ای به نسبت پایداری کل سیستم علاقه دارند، استفاده از توزیع تحت‌آزمون دبیان را که شامل آخرین نسخه از نرم‌افزارها بدون وجود باگ‌های اساسی است، انتخاب کنند. در نهایت، توسعه‌دهندگان و کاربران حرفه‌ای که علاقه‌مند به اجرای آخرین فناوری‌های موجود هستند، می‌توانند با استفاده از توزیع ناپایدار دبیان، ریسک سردرد کشیدن و باگ‌های جدید در آخرین نسخه از نرم‌افزارها را به جان بخرند. برای هر فردی نسخه‌ای از دبیان وجود دارد!
ترتیب زمانی مراحل بسته‌بندی یک برنامه در دبیان

شكل 1.4. ترتیب زمانی مراحل بسته‌بندی یک برنامه در دبیان

1.6.5. وضعیت شاخه‌های پایدار سابق و پایدار قدیمی

هر نسخه پایدار شامل چرخه حیاتی تقریباً ۵ ساله است و امکان انتشار نسخه‌های جدید هر ۲ سال یکبار را فراهم می‌آورد، در هر دوره زمانی تنها ۳ انتشار قابل پشتیبانی وجود خواهند داشت. زمانی که یک انتشار پایدار جدید اتفاق می‌افتد، نسخه پیشین به پایدار سابق و نسخه قبل از آن به پایدار قدیم تغییر نام می‌دهد.
پشتیبانی بلند مدت (LTS) دبیان یک رویکرد جدید در پروژه به حساب می‌آید: مشارکت‌کنندگان انفرادی و شرکت‌های گوناگون به یکدیکر پیوستند تا تیم LTS دبیان را تشکیل دهند. نسخه‌های قدیمی‌تر که دیگر تحت حمایت تیم امنیتی دبیان قرار ندارند به این تیم جدید واگذار می‌گردند.
تیم امنیتی دبیان، پشتیبانی امنیتی انتشار پایدار و پایدار سابق دبیان را بر عهده می‌گیرد (اما تنها با فاصله زمانی یک سال با انتشار نسخه پایدار فعلی). این مقدار به سه سال پشتیبانی برای هر نسخه می‌رسد. تیم LTS دبیان (دو) سال باقیمانده از پشتیبانی امنیتی را بر عهده می‌گیرد تا بازه زمانی ۵ ساله را برای کاربران ممکن سازد تا آن‌ها بتوانند از نسخه N به N+2 بروزرسانی کنند.