安定版のリリースブランチから、ソースコードのtarボールがいったん作成されると、 正式なリリースの手続きが始まります。しかし、tarボールを世界中で利用できるように する前にはテストを行い、最低限の、通常は3人以上の開発者からリリースしてよいとの同 意をもらっておくべきです。この手続きは、明らかな欠陥を探すために単にリリースを調 べることではありません。理想を言えば、開発者がtarボールをダウンロードし、インスト ールしたばかりのシステム上でそれをビルドし、インストールして自動回帰テスト(8章ボランティアの管理 の 「自動テスト」 を参照してください) を実行し、 さらに手動でテストをいくらかしておくべきでしょう。これらのチェックや、プロジ ェクトが持っているリリース時のチェックリストの項目をすべてクリアすれば、開発者は GnuPG(http://www.gnupg.org/) や PGP(http://www.pgpi.org/)、 または PGP と互換性のある他のプログラムを使ってtarボールに電子署名を行います。
ほとんどのプロジェクトでは、開発者はプロジェクトが共有している鍵を使わず、 自分の鍵を使って電子署名をします。そしてできるだけ多くの (すなわち、最低限 の人数が必要という意味であって、署名する開発者の数を限ればいいという意味で はありません) 開発者が同じtarボールに署名します。署名する開発者が多くなれば なるほど、多くテストされているということになり、セキュリティに関心があるユー ザーが、そのtarボールから自分が信頼するルートを見つけられる可能性が高くなります。
開発者達からリリースしてよいとの同意をもらったら、リリース(つまり、
すべてのtarボール、zipファイル、そして配布される他のあらゆるフォー
マットのファイル) は、電子署名と MD5/SHA1のチェックサム(http://en.wikipedia.org/wiki/Cryptographic_hash_function を参照
してください) と一緒にプロジェクトのダウンロードエリアに置きましょう。
これには標準的なやり方がいくつかあります。ひとつは、それぞれのリリー
スするパッケージを、対応する電子署名を記したファイルと、チェックサム
が書かれたファイルと一緒に置くことです。
たとえば、リリースするパッケージのひとつが、scanley-2.5.0.tar.gz
だとすると、同じディレクトリにそのtarボールに行った電子署名が含まれている
scanley-2.5.0.tar.gz.asc と、MD5 チェックサムを記した
scanley-2.5.0.tar.gz.md5 や、 SHA1チェックサムを記した
scanley-2.5.0.tar.gz.sha1 を置いておきます。
別の方法として、リリースするパッケージに対する全ての電子署名を
scanley-2.5.0.sigs のようなひとつのファイルに集めておく
ことがあります。同じやり方がチェックサムにも使えます。
どの方法を使っても構いません。単純な手続きに留めるようにし、それを 明確に文書化するようにしましょう。そして、以後のリリースに対しても それを一貫して適用するようにします。このように、電子署名とチェック サムをつける目的は、自分が受け取ったコピーが悪意がある人間によって 改竄されていないことを確認する手段をユーザーに与えることです。 ユーザーはダウンロードしたコードをすぐに自分のマシンで実行してしま います — つまり、コードが改竄されていれば、攻撃者がそのデータ にバックドアを仕掛けることができてしまいます。 セキュリティに関して偏執的なユーザーについては、この章の後の方にある 「セキュリティリリース」 を参照してください。
多くの変更が加えられた重要なリリースでは、多くのプロジェクトは好んで リリース候補 をはじめにリリースします。
たとえば、scanley-2.5.0 をリリースする前に scanley-2.5.0-beta1 をリリースするといった具合です。
リリース候補を出す目的は、正式なリリースを行う前に、コードを広くテストしてもらうことです。
問題が見つかれば、それはリリースブランチで修正され、新しいリリース候補が(scanley-2.5.0-beta2のような形で)リリースされます。
このサイクルは、見過ごせないバグが残っていない状態になるまで続けられ、その時点で最後のリリース候補が正式なリリースとなります — つまり、最後のリリース候補と正式なリリースの唯一の違いは、バージョン番号の識別子を除いた点だけ、ということになります。
ほとんどの点で、リリース候補は実際の正式リリースと同じように扱うようにします。 alpha、beta、そして rc といった識別子は、保守的なユーザーに対して正式リリースまで待つように警告するものであればそれで十分です。 そしてもちろん、リリース候補をアナウンスする電子メールは、リリース候補を出す目的がフィードバックを求めるためのものであることを記しておきましょう。 それ以外は、リリース候補に対して正式なリリースと同じだけの注意を払うようにします。 結局は、衆目の眼に晒すことはバグを発見する最高の方法ですし、 リリース候補が最終的に正式リリースになるかどうかわからないからこそ、 開発者はリリース候補を人々に使ってもらいたいと願うのです。
リリースを告知するのは、オープンソースソフトウェアを開発するときに起こる他のイベントと似ていますし、 その手続きも 6章コミュニケーション の 「宣伝・広報」 で説明している方法に従うとよいでしょう。 ただ、リリースを告知する場合には特別な点がいくつかあります。
リリースしたtarボールのダウンロード先URLを示す場合は、必ず MD5/SHA1 チェックサムと、 電子署名ファイルの場所も同時に示すようにしましょう。 リリースの告知は複数の場所 (メーリングリストやニュースページなど) で行われるため、 こうすることでユーザーがチェックサムの情報を複数の情報源から得ることができ、 最も強くセキュリティに関心を持つユーザーが、 チェックサムが改竄されていなかったことを確信できるようになります。 電子署名ファイルへのリンクを複数回張ったとしても、 その電子署名ファイルがより安全になるわけではありませんが、 プロジェクトがセキュリティに真面目に取り組んでいることを人々 (特にプロジェクトを間近で追いかけていない人) が再び確認できます。
電子メールとニュースページで告知をするときは、 リリースを宣伝する文章以上の情報も含めるようにし、 ユーザーがなぜアップグレードすべきかがわかるように、 関連する CHANGES ファイルの部分を必ず含めるようにしましょう。 この重要性は、正式なリリースのときも、リリース候補の場合でも同様に当てはまります。 バグ修正と新機能の内容を示すことは、ユーザーにリリース候補を試すように誘う意味で重要です。
最後に、開発チームとテスター、そして優れたバグ報告に時間を割いてくれた全てのユーザーに対して感謝の言葉を忘れないようにしましょう。 しかし、個人で巨大な仕事をする責任があった人がいない限り、特定の人を名指ししてはいけません。その仕事の価値はプロジェクトのメンバー全員がよーく知っていることですから。 クレジットの洪水に脚をとられないように注意しましょう。(8章ボランティアの管理 の 「クレジット」 を参照してください)