Product SiteDocumentation Site

1.6. Vòng đời của một bản phát hành

Dự án sẽ có đồng thời từ ba đến sáu phiên bản khác nhau của mỗi chương trình, mang tên Experimental, Unstable, Testing, Stable, Oldstable, and even Oldoldstable. Mỗi phiên bản tương ứng với một giai đoạn phát triển khác nhau. Để dễ hiểu hơn, chúng ta cần xem xét vòng đời của một phần mềm, từ lúc bắt đầu được packaging cho đến lúc được thêm vào một phiên bản Debian ổn định.

1.6.1. Tổng quan về bản Experimental

Đầu tiên ta cần xem xét đến trường hợp bản phân phối Experimental: đó là một tập các package Debian tương ứng với phần mềm hiện đang được phát triển, và không nhất thiết phải hoàn thiện, điều đó giải thích cho tên gọi của nó. Không phải package nào cũng qua được bước này; nhiều developer thêm các package vào đây nhận feedback từ những người dùng kinh nghiệm (hoặc can đảm) hơn.
Trái lại, bản phân phối này thường xuyên chứa những thay đổi quan trọng đối với base package (package gốc), sẽ được tích hợp vào bản Unstable cùng với các lỗi nghiêm trọng có thể gây ra hậu quả khôn lường. Do đó, nó là một bản phân phối hoàn toàn cô lập, các package của nó không bao giờ được ghép vào phiên bản khác (ngoại trừ khi maintainer của ftpmaster trực tiếp can thiệp vào). Nó cũng không khép kín: chỉ một tập con các package hiện tại xuất hiện trong bản Experimental, và nó thường không bao gồm hệ thống gốc (base system). Do đó, bản phân phối này chủ yếu dùng để kết hợp với các bản phân phối khép kín khác, chẳng hạn như Unstable.

1.6.2. Tổng quan về bản Unstable

Chúng ta quay lại một trường hợp package điển hình. Người maintainer tạo ra package ban đầu, sau đó được biên dịch cho phiên bản Unstable và cho lên ftp-master.debian.org server. Sự kiện đầu tiên gồm có kiểm tra và xác định tính hợp lệ từ ftpmasters. Sau đó phần mềm sẽ có mặt trong bản phân phối Unstable, chính là bản phân phối “tối tân (cutting-edge)” được chọn bởi những người dùng quan tâm đến các package luôn được cập nhật hơn là lo lắng về các lỗi nghiêm trọng. Họ vọc chương trình và thử nghiệm nó.
Nếu gặp lỗi, họ sẽ báo cáo cho maintainer của package. Sau đó maintainer sẽ chuẩn bị các bản tốt hơn, và upload lên server.
Package mới được cập nhật sẽ được update trên tất cả Debian mirror khắp thế giới chỉ trong vòng sáu giờ đồng hồ. Người dùng test những chỗ được điều chỉnh và tìm ra những vấn đề khác từ các thay đổi. Nhiều update được diễn ra nhanh chóng. Trong thời gian này, các autobuilder robot nhảy vào cuộc chơi. Các maintainer thường chỉ có một máy PC truyền thống và biên dịch package của họ trên kiến trúc amd64 (hoặc i386); các autobuilder sẽ tự động biên dịch ra các phiên bản dành cho các hệ kiến trúc máy tính khác. Một số biên dịch bất thành; người maintainer sẽ nhận được một báo cáo lỗi chỉ ra vấn đề, sau đó sẽ được chỉnh sửa vào các phiên bản tiếp theo. Khi lỗi được phát hiện bởi chuyên gia, bản báo cáo lỗi có thể được gửi kèm một bản patch sẵn sàng để sử dụng.
Biên dịch một package bằng các autobuilder

Hình 1.2. Biên dịch một package bằng các autobuilder

1.6.3. Tích hợp vào bản Testing

Một lúc sau, package sẽ hoàn thiện; được biên dịch trên tất cả các kiến trúc máy tính, nó sẽ không được trải qua các thay đổi gần nhất. Nó trở thành ứng viên cho việc thêm vào bản phân phối Testing — một nhóm các package Unstable được lựa chọn dựa trên một số tiêu chí về mặt định lượng. Hàng ngày một chương trình sẽ tự động chọn ra các package để thêm vào bản Testing, dựa trên các thành phần đảm bảo một level nhất định về chất lượng:
  1. ít các lỗi nghiêm trọng, hoặc, ít nhất là ít lỗi hơn phiên bản hiện tại nằm trong bản Testing;
  2. ít nhất 10 ngày nằm trong bản Unstable, đủ thời gian để tìm ra và báo cáo các lỗi kiêm trọng;
  3. biên dịch thành công trên tất cả kiến trúc máy tính được chính thức hỗ trợ;
  4. các dependency có thể được satisfied trong bản Testing, hoặc ít nhất có thể được chuyển đến đó cùng với các package đang xét đến.
Hệ thống này rõ ràng không thể không phạm sai lầm; các lỗi nghiêm trọng thường xuyên được tìm thấy trong các package được thêm vào bản Testing. Hiện tại, nhìn chung là có hiệu quả, và bản Testing ít vấn đề hơn nhiều so với bản Unstable, là sự thỏa hiệp giữa tính ổn định và tính mới lạ.

1.6.4. Đi từ Testing đến Stable

Giả sử package của chúng ta giờ đã được thêm vào bản Testing. Cho đến khi có chỗ để phát triển , maintainer buộc phải tiếp tục cải thiện nó và bắt đầu lại quá trình từ bản Unstable (nhưng việc thêm nó vào sau bản Testing thường nhanh hơn: trừ khi nó đã thay đổi đáng kể, tất cả dependencies của nó đều available). Khi đạt được độ hoàn hảo, maintainer đã hoàn thành công việc của họ. Bước tiếp theo là thêm vào bản Stable, trên thực tế, một bản copy đơn giản của bản Testing tại một thời điểm được chọn bởi Release Manager. Lý tưởng là quyết định này được đưa ra khi bộ cài đã sẵn sàng, và khi không có chương trình nào trong bản Testing có các lỗi nghiêm trọng đã được biết đến.
Bởi vì thời điểm này không bao giờ thực sự đến, trên thực tế, Debian buộc phải thỏa hiệp: xóa đi các package mà người maintainer đã không kịp sửa lỗi đúng thời hạn, hoặc đồng ý phát hành một bản phân phối với một số lỗi trong hàng ngàn chương trình. Release Manager sẽ thông báo trước một chu kì freeze, trong thời gian đó mỗi cập nhật đến bản Testing phải được phê duyệt. Mục tiêu ở đây là ngăn bất kì phiên bản mới nào (và lỗi mới của nó), và chỉ phê duyệt các lỗi đã được sửa.
Con đường của một package qua nhiều phiên bản Debian khác nhau

Hình 1.3. Con đường của một package qua nhiều phiên bản Debian khác nhau

Sau khi phát hành một phiên bản ổn định mới, Stable Release Manager quản lý tất cả việc phát triển xa hơn (gọi là “revisions”, vd: 7.1, 7.2, 7.3 cho phiên bản 7). Các cập nhật này thêm vào các bản vá bảo mật một cách hệ thống. Chúng chỉ thêm vào các chỉnh sửa quan trọng nhất (maintainer của một package phải chứng minh được mức độ quan trọng của vấn đề mà họ muốn sửa sai để bản cập nhật của họ được thêm vào).
Vào cuối hành trình, package giả định của chúng ta đã được thêm vào bản phân phối stable. Hành trình này, chưa kể tới khó khăn của nó, giải thích các lần chậm trễ đáng kể ngăn cách giữa các bản release Debian Stable. Điều này góp phần vào uy tín về chất lượng của Debian. Hơn nữa, phần lớn người dùng hài lòng khi sử dụng một trong ba bản phân phối available cùng lúc. Quản trị hệ thống, quan tâm trên hết về tính ổn định của server của họ, không cần biết đến các phiên bản mới nhất và tuyệt với nhất của GNOME; họ có thể chọn Debian Stable, và họ sẽ hài lòng. Người dùng cuối, quan tâm đến bản mới nhất của GNOME hay KDE hơn là tính ổn định, sẽ thấy rằng Debian Testing là sự thỏa hiệp giữa việc ít các vấn đề nghiêm trọng và dùng được phần mềm mới. Cuối cùng, các developer và người dùng có kinh nghiệm hơn có thể sẽ làm khác, thử nghiệm tất cả các phát triển mới nhất trong Debian Unstable ngay tại chỗ, chịu rủi ro về các lỗi kế thừa từ bất kì phiên bản mới nào của một chương trình. Tất cả họ đều sở hữu Debian!
Chu kỳ phát triển theo thời gian của một chương trình được package bởi Debian

Hình 1.4. Chu kỳ phát triển theo thời gian của một chương trình được package bởi Debian

1.6.5. Tổng quan về bản Oldstable và bản Oldoldstable

Mỗi bản phát hành Stable có vòng đời khoảng 5 năm và việc release diễn ra mỗi 2 years, có thể có đến 3 bản phát hành được hỗ trợ tại mỗi thời điểm. Khi một bản phát hành ổn định mới được tung ra, các bản phát hành trước trở thành Oldstable và bản trước nữa trở thành Oldoldstable.
Bản phát hành Hỗ trợ dài hạn (LTS) này của Debian là một sáng kiến gần đây: cộng tác viên và các công ty tham gia vào lực lượng tạo ra team Debian LTS. Các bản phát hành cũ hơn không còn được hỗ trợ bởi đội ngũ bảo mật của Debian nữa sẽ không thuộc trách nhiệm của team mới này.
Đội ngũ bảo mật của Debian xử lý các hỗ trợ bảo mật trong bản phát hành Stable hiện tại và cũng cho bản Oldstable (nhưng chỉ cho đến khi đảm bảo trùng một năm với bản phát hành stable hiện tại). Thời gian này vào khoảng roughly ba năm hỗ trợ cho mỗi bản phát hành. Team Debian LTS hỗ trợ bảo mật cho (hai) năm cuối cùng để mỗi bản phát hành được hưởng lợi ít nhất 5 năm hỗ trợ và người dùng có thể nâng cấp từ bản N lên bản N+2.