最初に特殊な例である実験版ディストリビューションについて見てみましょう。具体的に言えば、これは現在開発中のソフトウェアに相当する Debian パッケージのグループで、名前の示す通り開発を終えている必要はありません。すべてのパッケージがこのステップを踏む必要はありませんが、一部の開発者はより経験豊富な (優れた) ユーザからのフィードバックを得るためにパッケージをここに追加します。

別の側面から話をすると、実験版ディストリビューションは基盤パッケージに対する重要な変更を組み込む際によく使われます。この変更にバグが含まれていた場合、その基盤パッケージを不安定版に組み込むと深刻な影響をおよぼすかもしれません。そんなわけで、実験版は完全に隔離されたディストリビューションになっており、実験版に含まれるパッケージは決して他のバージョンに移行することはありません (メンテナまたは ftpmaster からの介入という例外を除きます)。また、実験版は自己完結していません。具体的に言えば、実験版の中には既存のパッケージの一部だけが含まれており、基盤システムは含まれません。それゆえ実験版は通常、不安定版などの自己完結している他のディストリビューションと組み合わせて利用されます。

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.

ユーザはバグに遭遇すると、バグをパッケージメンテナに報告します。メンテナは定期的に修正済みバージョンを用意し、ftp-master.debian.org サーバにアップロードします。

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.

しばらくするとパッケージは成熟するでしょう。さらにすべてのアーキテクチャ上でパッケージがコンパイルされ、パッケージに対して最後に行った変更から十分な時間が経過するでしょう。こうなると、そのパッケージは将来テスト版ディストリビューションに組み込まれる対象になります。つまり不安定版に含まれる一部のパッケージは定量化できる基準に従って選ばれます。毎日あるプログラムが、以下に示す一定の品質水準を保証する要素を基に、テスト版に組み込むためのパッケージを自動的に選びます。

この移行システムが完全無欠でないことは明らかです。それどころか、深刻なバグは通常テスト版に組み込まれたパッケージから見つかります。とは言うものの、この移行システムは有効です。さらにテスト版は不安定版に比べて問題がはるかに少なく、多くの人にとって安定性と新規性の良い妥協案です。

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.

実際にはこのような理想的瞬間は絶対に来ないので、Debian は妥協しています。具体的に言えば、メンテナが時間通りにバグを修正できなかったパッケージを削除したり、多数のプログラムが数個のバグを抱えた状態でディストリビューションをリリースすることに同意したりします。リリースマネージャは事前にフリーズ期間をアナウンスし、テスト版への更新はこの期間中に承認されなければいけません。フリーズ期間を設ける目的は、バージョンが新しくなる更新 (と新たなバグの混入) を禁止し、現在のバージョンに対するバグ修正の更新だけを受け入れることです。

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!

各安定版リリースの寿命は約 5 年と予定されており、安定版は 2 年ごとにリリースされます。ある時点において最大で 3 種類のサポートされるリリースが存在することになります。新しい安定版がリリースされた時点で、古い安定版は旧安定版になり、さらに旧安定版は前旧安定版になります。

Debian リリースの長期サポート (LTS) は最近の新たな取り組みです。Debian LTS チームの設立には Debian LTS プロジェクトに参加している各貢献者と企業が懸命に取り組みました。Debian セキュリティチームがサポートしない古いリリースはこの新しい Debian LTS チームの管理下に移ります。

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.