Debian プロジェクトはある時点でそれぞれのプログラムの 3 種類から 6 種類の異なるバージョンを持っており、実験版、不安定版、テスト版、安定版、旧安定版、前旧安定版、のように名づけられています。各バージョンは開発の異なる段階に相当します。違いを十分に理解するために、どのような順序でプログラムが最初のパッケージングから Debian の安定版に組み込まれるかを見てみましょう。
最初に特殊な例である実験版ディストリビューションについて見てみましょう。具体的に言えば、これは現在開発中のソフトウェアに相当する 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 サーバにアップロードします。
新たに更新されたパッケージはすべて、6 時間以内に世界中に存在するすべての Debian アーカイブミラーで更新されます。そしてユーザが修正をテストし、変更したことで生じる別の問題を探します。いくつかの更新は素早くなされるかもしれません。これらの間に自動ビルドロボットが活動を始めます。多くの場合、メンテナは古い PC を一台だけ持っており、amd64 (または i386) アーキテクチャで自分が担当しているパッケージをコンパイルしています (メンテナが source-only アップロードを選択した場合、パッケージのコンパイルは必要ありません)。自動ビルドロボットはコンパイル作業を引き受け、すべての他のアーキテクチャ向けのバージョンを自動的にコンパイルします。いくつかアーキテクチャではコンパイルが失敗するかもしれません。その場合、メンテナは問題の内容を含んだバグ報告を受け取り、このバグは次のバージョンで修正されます。問題となっているアーキテクチャの専門家がバグを発見した場合、そのバグ報告にはすぐに使えるパッチが添えられているかもしれません。
しばらくするとパッケージは成熟するでしょう。さらにすべてのアーキテクチャ上でパッケージがコンパイルされ、パッケージに対して最後に行った変更から十分な時間が経過するでしょう。こうなると、そのパッケージは将来テスト版ディストリビューションに組み込まれる対象になります。つまり不安定版に含まれる一部のパッケージは定量化できる基準に従って選ばれます。毎日あるプログラムが、以下に示す一定の品質水準を保証する要素を基に、テスト版に組み込むためのパッケージを自動的に選びます。
深刻なバグがないこと、もしくは現時点でテスト版に組み込まれているバージョンよりもバグの数が少ないこと。
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);
公式にサポートされているすべてのアーキテクチャ上でコンパイルに成功していること。
テスト版で依存関係が満たされていること。依存関係が満たされていない場合、依存パッケージの準備ができ次第そのパッケージと一緒にテスト版に組み込まれます。
この移行システムが完全無欠でないことは明らかです。それどころか、深刻なバグは通常テスト版に組み込まれたパッケージから見つかります。とは言うものの、この移行システムは有効です。さらにテスト版は不安定版に比べて問題がはるかに少なく、多くの人にとって安定性と新規性の良い妥協案です。
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 は妥協しています。具体的に言えば、メンテナが時間通りにバグを修正できなかったパッケージを削除したり、多数のプログラムが数個のバグを抱えた状態でディストリビューションをリリースすることに同意したりします。リリースマネージャは事前にフリーズ期間をアナウンスし、テスト版への更新はこの期間中に承認されなければいけません。フリーズ期間を設ける目的は、バージョンが新しくなる更新 (と新たなバグの混入) を禁止し、現在のバージョンに対するバグ修正の更新だけを受け入れることです。
新しい安定版がリリースされるとそれ以降は、安定版リリースマネージャが安定版に対するすべての追加的開発を管理します (追加的開発は「リビジョン」と呼ばれます。たとえばバージョン 7 のリビジョンは 7.1、7.2、7.3 などです)。これらの更新にはすべてのセキュリティパッチおよび最も重要と判断された修正が体系的に組み込まれています (パッケージのメンテナが安定版に修正を組み込んでもらうためには修正を望む問題の重大性を安定版リリースマネージャに証明しなければいけません)。
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 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".
