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
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.
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.
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. The maintainer uploads the package sources (without any precompiled package). The autobuilders take over and automatically compile versions for all supported 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. 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:
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ợ;
í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;
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);
dependencies that can be satisfied in Testing, or that can at least be moved there together with the package in question;
automatic quality tests of the package (autopkgtest) — if defined — don't show any regression.
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
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.
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.
After the release of a new stable version, the Stable Release Managers manage all further development (called “revisions”, ex: 10.1, 10.2, 10.3 for version 10). 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.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.
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 release benefits from at least 5 years of support and so that users can upgrade from version N to N+2, for example, from Debian 9
Stretch to Debian 11
Bullseye.