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

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

典型的なパッケージの場合に戻りましょう。メンテナが不安定版用にコンパイルされた最初のパッケージを作成し、ftp-master.debian.org サーバに置きます。その後、ftpmaster がパッケージを検査検証します。その後、ソフトウェアは不安定版ディストリビューションで利用できるようになります。不安定版ディストリビューションは深刻なバグを心配するよりも、最新のパッケージを使うことを望むユーザが使う「最先端の」ディストリビューションです。そのようなユーザが最新のプログラムを見つけてテストします。

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

新たに更新されたパッケージはすべて、6 時間以内に世界中に存在するすべての Debian アーカイブミラーで更新されます。そしてユーザが修正をテストし、変更したことで生じる別の問題を探します。いくつかの更新は素早くなされるかもしれません。これらの間に自動ビルドロボットが活動を始めます。多くの場合、メンテナは古い PC を一台だけ持っており、amd64 (または i386) アーキテクチャで自分が担当しているパッケージをコンパイルしています (メンテナが source-only アップロードを選択した場合、パッケージのコンパイルは必要ありません)。自動ビルドロボットはコンパイル作業を引き受け、すべての他のアーキテクチャ向けのバージョンを自動的にコンパイルします。いくつかアーキテクチャではコンパイルが失敗するかもしれません。その場合、メンテナは問題の内容を含んだバグ報告を受け取り、このバグは次のバージョンで修正されます。問題となっているアーキテクチャの専門家がバグを発見した場合、そのバグ報告にはすぐに使えるパッチが添えられているかもしれません。

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

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

われわれのパッケージが今現在テスト版に組み込まれたと仮定しましょう。パッケージに改善の余地がある限り、パッケージのメンテナはそのパッケージを改善し続け、不安定版からの一連の手順を最初からやり直さなければいけません (その後テスト版までは素早く組み込まれることが多いです。ただしこれはパッケージが大きく修正されておらず、すべての依存関係がテスト版で満たされている場合に限ります)。パッケージが完成の域に達すると、メンテナの作業は完了です。次のステップは安定版ディストリビューションへの組み込みです、実際のところこれはリリースマネージャが選んだ時点におけるテスト版の単純なコピーです。理想的にはこの決断はインストーラの準備が整った時点、そしてすべてのテスト版に含まれるプログラムで既知の致命的バグが解決された時点に行われます。

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

新しい安定版がリリースされるとそれ以降は、安定版リリースマネージャが安定版に対するすべての追加的開発を管理します (追加的開発は「リビジョン」と呼ばれます。たとえばバージョン 7 のリビジョンは 7.1、7.2、7.3 などです)。これらの更新にはすべてのセキュリティパッチおよび最も重要と判断された修正が体系的に組み込まれています (パッケージのメンテナが安定版に修正を組み込んでもらうためには修正を望む問題の重大性を安定版リリースマネージャに証明しなければいけません)。

最後に、仮想パッケージが安定版ディストリビューションに組み込まれます。ここに到達するまでには大変な苦労があり、Debian 安定版のリリースが極めてゆっくりと進む理由がお分かりになったと思います。安定版リリースの遅さは品質評価に貢献します。しかも、大多数のユーザは同時に利用できる 3 つのディストリビューションのうち 1 つを使えば満足です。システム管理者は、何よりもまず彼らのサーバの安定性を重要視しており、最新バージョンの GNOME は必要ありません。従ってシステム管理者は Debian 安定版を選んで、それに満足するでしょう。エンドユーザは、強固な安定性よりも最新バージョンの GNOME や KDE Plasma に興味があり、Debian テスト版を選ぶでしょう。テスト版は深刻な問題が少なく、比較的新しいソフトウェアが使えるという意味で安定版と不安定版の良い妥協点です。最後に、開発者と経験豊富なユーザが先駆者となり、Debian 不安定版になされたすべての最新の開発を真っ先にテストし、面倒事とプログラムの新しいバージョンにつきものであるバグに苦しむという危険を冒します。人それぞれ好みの Debian があるのです!

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

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

Debian セキュリティチームは現在の安定版リリースと旧安定版リリースのセキュリティサポートを担当します (旧安定版に対してサポートが保証される期間は現在の安定版のリリース後 1 年間です)。Debian セキュリティチームによるセキュリティサポート期間は各リリースにつきおよそ 3 年間になります。Debian LTS チームはセキュリティサポートの最後の 2 年間を担当します。そうすれば各リリースは少なくとも 5 年間のサポートを受けることが可能ですし、ユーザはバージョン N から N+2 にアップグレードを行うことが可能になります。