ほとんどの成熟したプロジェクトは、複数のリリースラインを平行して管理しています。 たとえば バージョン 1.0.0 がリリースされた後は、 プロジェクトが明示的にリリースラインの維持をやめるまで、 マイクロ(バグ修正)リリースを 1.0.1, 1.0.2 などの形でリリースするようにします。 ただ (マイナー番号が上がった) 1.1.0 をリリースすることが、 1.0.x ラインの維持をやめる十分な理由にはならないことに注意してください。 たとえば、新しいマイナー(メジャー)シリーズのはじめのリリースは絶対にアップグレードの対象にしないことをポリシーにしているユーザーもいます — つまり、彼らはたとえば 1.1.0 の間は他のユーザーにバグを探させ、 1.1.1 のリリースを待っているのです。これは必ずしも自分勝手な行動とは言えません。 (彼らは、新機能や、バグ修正の恩恵を受けることを控えていることも覚えておきましょう) ただ、理由が何であれ、彼らはアップグレードをとても慎重に行うと決めただけなのです。 よって、プロジェクトが 1.1.0 のリリースを目前にして 1.0.3 で重大なバグを発見した場合は、 ちょっと厳しいですが 1.1.0 でその修正を行い、 すべての 1.0.x 系を使っているユーザーにアップグレードを推奨することになるでしょう。 この場合、1.1.0 と 1.0.4 を両方リリースしたとして、開発者とユーザーの双方がハッピーでしょうか？ そうではないですよね。
1.1.x ラインの維持がうまくいくと、プロジェクトは 1.0.x ラインの 維持をやめる と宣言することができます。 この宣言は公式なものとして行いましょう。その告知は単独で行うこともできますし、 1.1.x ラインのリリース告知と一緒に行うこともできます。どの方法をとるにしても、 ユーザーは古いリリースラインが維持されなくなることを知らなければいけません。 なぜなら、その告知に従って、ユーザーはアップグレードをする決断ができるからです。
プロジェクトによっては、以前のリリースラインのサポートを保証する期間を設定するところもあります。 オープンソースの文脈でいえば、"サポート" とはそのリリースラインに対するバグ報告を受け付け、 バグが十分出尽くすまでメンテナンスリリースを行うということです。 一方で、明示的にサポート期間は設定しないものの、 古いリリースラインを使っているユーザーの数を把握するため、 バグ報告の数を見張るプロジェクトもあります。 古いリリースラインを使うユーザーの率がある値より下がった時点で、 プロジェクトはそのラインの維持をやめると宣言し、サポートをやめるのです。
リリースを行うごとに、必ず ターゲットバージョン または ターゲットとなるマイルストーン をバグ報告システムに設定するようにしましょう。 これは、ユーザーが適切なリリースに対してバグを報告できるようにするためです。 開発中の最新のソースコードに対しては、 "development" や "latest" と呼ばれるターゲット名を設定することも忘れないでください。 なぜなら、ユーザーによっては、 — 活発な開発者だけではありません — 公式なリリースより新しいコードを実行しているからです。
セキュリティに関わるバグを扱う方法の詳細は6章コミュニケーション の 「セキュリティ脆弱性の告知」 で扱っていますが、 セキュリティリリースを行うにあたっては、特に議論すべきことがいくつかあります。
セキュリティリリース とは、 セキュリティ脆弱性を修正するためだけに行われるリリースです。 脆弱性を修正したコードはリリースが公になるまで明らかにできません。 これは修正がリリースの日までリポジトリにコミットできないだけでなく、 リリースされるまで公の場でテストできないことも意味しています。 開発者は、当然のことながら自分たちで修正箇所を調べ、内部でテストすることができますが、 広くユーザーにテストしてもらうことはできないのです。
このようにテストが不足することから、 セキュリティリリースは常に既に存在するリリースに対して修正を行い、 それ以外には 何も変更しない ようにすべきです。 これは、テストなしに多くの変更をリリースすればするほど、新しいバグが発生する可能性が高くなるうえ、 新しいセキュリティ上の脆弱性が発生する可能性すらあるからです！ この保守的なやり方は、セキュリティ上の修正を展開する必要があるシステム管理者だけでなく、 セキュリティ上の修正とそれ以外の修正を同時にマシンに展開しないというアップグレードポリシーを持つ管理者にも馴染みやすいものです。
セキュリティリリースを行うために、ユーザーをちょっと騙す場合もあります。 たとえば、プロジェクトが 1.1.3 のリリースに向けて動いていて、 1.1.2 に対するバグ修正を行うと公に宣言しているときに、 セキュリティに関わるバグ報告が行われた場合です。 当然、開発者達はその修正がリリースされるまでセキュリティ問題について話すことはできません。 つまり、そのときまで 1.1.3 は計画通り 1.1.2 のバグ修正が含まれたものになると言い続けなければならないのです。 しかし、実際に 1.1.3 が出てみると、1.1.2 にセキュリティバグの修正が加わったことだけが変更点で、 他の修正は 1.1.4 に先送りされてしまっていました。(これはもちろん、セキュリティバグの修正に加え、 他の修正も 1.1.4 には含まれることになるということです)
セキュリティの修正だけが含まれたリリースであることを示すために、 リリース番号に追加の構成要素を加えることもできます。 たとえば、 1.1.2.1 というリリース番号は、 1.1.2 に対してセキュリティ修正だけが加わったリリースだと区別できます。 そしてそれより "大きい" リリース番号 (e.g. 1.1.3, 1.2.0 など) は、 同じセキュリティ修正が加えられたリリースであるとわかります。 一方、プロジェクトを間近で追いかけていない人にとっては、 ほとんどの場合は3つの数字でリリース番号が構成されているのに、 ランダムに、ときどき4つの番号を見ると少し混乱する可能性があります。 私が見てきたほとんどのプロジェクトは、リリース番号を一貫させる方針を採用し、 セキュリティの修正が含まれたリリースの場合も、 たとえそれが他のリリース計画を番号ひとつ分ずらすことを意味するとしても、 最新リリースの次の番号を使っています。