前提条件¶リリース手順の前提条件は以下の通りです。(sid)コマンドラインの実行例はzsh作業ディレクトリ例は以下を使用します。しておくべきパッケージを示します。(sid)を前提として説明しているため、その他の環境では適宜読み替えて下さい。bisonまた、Sphinxは常に最新のバージョンを使う事を推奨します。使用して最新のSphinxをインストールするようにして下さい。apt-getでインストールできるのは古いバージョンなので、Webサイトから最新版をダウンロードしてインストールすることをおすすめします。Vagrantで使用する仮想化ソフトウェア(VirtualBox、VMwareなど)がない場合、合わせてインストールしてください。VirtualBoxはsources.listにcontribセクションを追加すればapt-getでインストールできます。virtualboxまた、rubyのrakeパッケージを以下のコマンドによりインストールします。パッケージ署名用秘密鍵のインポート¶リリース作業ではRPMパッケージに対する署名を行います。その際、パッケージ署名用の鍵が必要です。Groongaプロジェクトでは署名用の鍵をリリース担当者の公開鍵で暗号化してリポジトリのpackages/ディレクトリ以下へと登録しています。新しいリリース担当者に任命されたばかりで、まだ自分用に暗号化された鍵が無い場合には、他のリリース担当者に依頼して署名用の鍵を暗号化してもらって下さい。リリース担当者はリポジトリに登録された秘密鍵を復号した後に鍵のインポートを以下のコマンドにて行います。Groongaの署名用の鍵を確認することができます。2012-04-24鍵をインポートしただけでは使用することができないため、インポートした鍵に対してtrust,signを行う必要があります。以下のコマンドを実行して署名を行います。quitこの作業は、新規にリリースを行うことになった担当者やパッケージに署名する鍵に変更があった場合などに行います。PPA用の鍵の登録¶この作業は、新規にリリースを行うことになった担当者のみ行います。[Launchpad](https://launchpad.net/)にアカウントを作成し、自分の普段使いの秘密鍵を登録した上で、他のリリース担当者に依頼して[Groongaチーム](https://launchpad.net/~groonga)に追加してもらって下さい。リリース作業用ディレクトリの作成¶Groongaのリリース作業ではリリース専用の環境下(コンパイルフラグ)でビルドする必要があります。リリース時と開発時でディレクトリを分けずに作業することもできますが、誤ったコンパイルフラグでリリースしてしまう危険があります。そのため、以降の説明では$GROONGA_DIR以下のディレクトリにリリース用の作業ディレクトリ(groonga.clean)としてソースコードをcloneしたものとして説明します。Groongaのソースコード取得¶リリース用のクリーンな状態でソースコードを取得するために$GROONGA_DIRにて以下のコマンドを実行します。groonga.cleanこの作業はリリース作業ごとに行います。Groongaのウェブサイトの取得¶GroongaのウェブサイトのソースはGroonga同様にgithubにリポジトリを置いています。update-latest-release)にてトップページのバージョンを置き換えることができるようになっています。Groongaのウェブサイトのソースコードを$GROONGA_ORG_PATHとして取得するためには、$GROONGA_DIRにて以下のコマンドを実行します。git@github.com:groonga/groonga.org.gitこれで、$GROONGA_ORG_PATHにgroonga.orgのソースを取得できます。cutterのソースコード取得¶Groongaのリリース作業では、cutterに含まれるスクリプトを使用しています。そこであらかじめ用意しておいた$HOME/work/cutterディレクトリにてcutterのソースコードを以下のコマンドにて取得します。git@github.com:clear-code/cutter.gitこれで、$CUTTER_SOURCE_PATHディレクトリにcutterのソースを取得できます。前回リリース時からの変更点を$GROONGA_CLONE_DIR/doc/source/news.rst(英語)にまとめます。ここでまとめた内容についてはリリースアナウンスにも使用します。前回リリースからの変更履歴を参照するには以下のコマンドを実行します。-1)..ログを^commitで検索しながら、以下の基準を目安として変更点を追記していきます。含めないもの内部的な変更(変数名の変更やらリファクタリング)具体的な変更点の記述方法は後述します。configureスクリプトの生成¶Groongaのソースコードをcloneした時点ではconfigureスクリプトが含まれておらず、そのままmakeコマンドにてビルドすることができません。$GROONGA_CLONE_DIRにてautogen.shを以下のように実行します。autogen.shこのコマンドの実行により、configureスクリプトが生成されます。configureスクリプトの実行¶Makefileを生成するためにconfigureスクリプトを実行します。リリース用にビルドするためには以下のオプションを指定してconfigureを実行します。--with-cutter-source-path=$HOME/work/cutter/cutterconfigureオプションである--with-groonga-org-pathにはGroongaのウェブサイトのリポジトリをcloneした場所を指定します。configureオプションである--with-cutter-source-pathにはcutterのソースをcloneした場所を指定します。以下のようにGroongaのソースコードをcloneした先からの相対パスを指定することもできます。--with-cutter-source-path=../../cutter/cutterあらかじめpackagesユーザでpackages.groonga.orgにsshログインできることを確認しておいてください。ログイン可能であるかの確認は以下のようにコマンドを実行して行います。指定して不安定版のリポジトリにアップロードするように指定します。--with-cutter-source-path=$HOME/work/cutter/cutter新任のリリース担当者は必ず、この方法でPPAのリポジトリにパッケージをアップロードできる事を確認しておいてください。update-latest-releaseコマンドでは、OLD_RELEASE_DATEに前回のリリースの日付を、NEW_RELEASE_DATEに次回リリースの日付(未来の日付)を指定します。2.0.2のリリースを行った際は以下のコマンドを実行しました。NEW_RELEASE_DATE=2012-04-29これにより、clone済みのGroongaのWebサイトのトップページのソース(index.html,ja/index.html)やRPMパッケージのspecファイルのバージョン表記などが更新されます。update-examplesの実行¶ドキュメントに埋め込まれている実行結果を更新するために、以下のコマンドを実行します。update-examplesdoc/source/examples以下が更新されるので、それらをコミットします。update-filesの実行¶ロケールメッセージの更新や変更されたファイルのリスト等を更新するために以下のコマンドを実行します。update-filesを実行すると新規に追加されたファイルなどが各種.amファイルへとリストアップされます。リリースに必要なファイルですので漏れなくコミットします。update-poの実行¶ドキュメントの最新版と各国語版の内容を同期するために、poファイルの更新を以下のコマンドにて実行します。update-poを実行すると、doc/locale/ja/LC_MESSAGES以下の各種.poファイルが更新されます。update-poコマンドの実行により更新した各種.poファイルを翻訳します。翻訳結果をHTMLで確認するために、以下のコマンドを実行します。いうファイルを適宜修正します。実行時に失われます)。ファイルを編集したら、再度poファイルとHTMLを更新するために以下のコマンドを実行します。html確認が完了したら、翻訳済みpoファイルをコミットします。リリースタグの設定¶リリース用のタグを打つには以下のコマンドを実行します。tag注釈タグを打った後にconfigureを実行することで、ドキュメント生成時のバージョン番号に反映されます。リリース用アーカイブファイルの作成¶リリース用のソースアーカイブファイルを作成するために以下のコマンドを$GROONGA_CLONE_DIRにて実行します。distこれにより$GROONGA_CLONE_DIR/groonga-(バージョン).tar.gzが作成されます。distを行うとversionが古いままになることがあります。--versionで表示されるバージョン表記が更新されないので注意が必要です。distで生成したtar.gzのversionおよびversion.shがタグと一致することを確認するのが望ましいです。パッケージのビルド¶リリース用のアーカイブファイルができたので、パッケージ化する作業を行います。パッケージ化作業は以下の3種類を対象に行います。Hat系(.rpm)Windows系(.exe,.zip)パッケージのビルドではいくつかのサブタスクから構成されています。ビルド用パッケージのダウンロード¶debパッケージのビルドに必要なパッケージをダウンロードするには以下のコマンドを実行します。downloadこれにより、lucid以降の関連する.debパッケージやソースアーカイブなどがカレントディレクトリ以下へとダウンロードされます。rpmパッケージのビルドに必要なパッケージをダウンロードするには以下のコマンドを実行します。downloadこれにより、GroongaやMySQLのRPM/SRPMパッケージなどがカレントディレクトリ以下へとダウンロードされます。Windowsパッケージのビルドに必要なパッケージをダウンロードするには以下のコマンドを実行します。downloadこれにより、Groongaのインストーラやzipアーカイブがカレントディレクトリ以下へとダウンロードされます。sourceパッケージに必要なものをダウンロードするには以下のコマンドを実行します。packages/source/filesディレクトリ以下へとダウンロードされます。Debian系パッケージのビルド¶Groongaのpackagesサブディレクトリに移動して、以下のコマンドを実行します。apache/arrowのリポジトリをcloneしたパスを指定します。現在サポートされているのは以下の通りです。i386/amd64正常にビルドが終了すると$GROONGA_CLONE_DIR/packages/apt/repositories配下に.debパッケージが生成されます。まとめてビルドできないこともあります。その場合にはディストリビューションごとやアーキテクチャごとなど、個別にビルドすることで問題が発生している箇所を切り分ける必要があります。正常にビルドができたら、packages/aptサブディレクトリに移動して以下のコマンドを実行します。$PACKAGES_GROONGA_ORG_REPOSITORYに移動し、以下のコマンドを実行します。apt:downloadパッケージのダウンロードが終わったら、以下のコマンドを実行し、パッケージへの署名からリポジトリの更新、アップロードを実行します。Hat系パッケージのビルド¶Groongaのpackages/yumサブディレクトリに移動して、以下のコマンドを実行します。yum:build現在サポートされているのは以下の通りです。x86_64ビルドが正常終了すると$GROONGA_CLONE_DIR/packages/yum/repositories配下にRPMパッケージが生成されます。repositories/yum/centos/6/x86_64/Packagesrepositories/yum/centos/7/x86_64/Packages正常にビルドができたら、packages/yumサブディレクトリに移動して以下のコマンドを実行します。$PACKAGES_GROONGA_ORG_REPOSITORYに移動し、以下のコマンドを実行します。yum:downloadパッケージのダウンロードが終わったら、以下のコマンドを実行し、パッケージへの署名からリポジトリの更新、アップロードを実行します。Windows用パッケージのビルド¶packages/windowsサブディレクトリに移動して、以下のコマンドを実行します。releaseを実行することでbuildからuploadまで一気に実行することができますが、途中で失敗することもあるので順に実行することをおすすめします。buildでクロスコンパイルを行います。正常に終了するとdist-x64/dist-x86ディレクトリ以下にx64/x86バイナリを作成します。packageが正常に終了するとzipアーカイブをfilesディレクトリ以下に作成します。installerが正常に終了するとWindowsインストーラをfilesディレクトリ以下に作成します。パッケージの動作確認¶ビルドしたパッケージに対しリリース前の動作確認を行います。Hat系の場合には本番環境へとアップロードする前にローカルのaptないしyumのリポジトリを参照して正常に更新できることを確認します。ここでは以下のようにrubyを利用してリポジトリをwebサーバ経由で参照できるようにします。grntestの準備¶TravisCIの結果が正常であれば、この手順はスキップして構いません。grntestを実行するためにはGroongaのテストデータとgrntestのソースが必要です。Groongaのソースを任意のディレクトリへと展開します。groonga-(バージョン).tar.gz次にGroongaのtest/functionディレクトリ以下にgrntestのソースを展開します。test/function/grntestという名前でgrntestのソースを配置します。grntestの実行方法¶grntestではGroongaコマンドを明示的に指定することができます。後述のパッケージごとのgrntestによる動作確認では以下のようにして実行します。test/function/run-test.sh最後にgrntestによる実行結果が以下のようにまとめて表示されます。passed.grntestでエラーが発生しないことを確認します。Debian系の場合¶Debian系の場合の動作確認手順は以下の通りとなります。Hat系の場合の動作確認手順は以下の通りとなります。Windows向けの場合¶テスト環境で新規インストール/上書きインストールを行うgrntestのアーカイブを展開してインストールしたバージョンでテストを実行するgrntestの正常終了を確認するzipアーカイブも同様にしてgrntestを実行し動作確認を行います。リリースアナウンスの作成¶リリースの際にはリリースアナウンスを流して、Groongaを広く通知します。news.rstに変更点をまとめましたが、それを元にリリースアナウンスを作成します。リリースアナウンスには以下を含めます。インストール方法へのリンクリリースのトピック紹介リリース変更点へのリンクリリース変更点(news.rstの内容)リリースのトピック紹介では、これからGroongaを使う人へアピールする点や既存のバージョンを利用している人がアップグレードする際に必要な情報を提供します。非互換な変更が含まれるのであれば、回避方法等の案内を載せることも重要です。参考までに過去のリリースアナウンスへのリンクを以下に示します。2.0.2http://osdn.jp/projects/groonga/lists/archive/dev/2012-April/000794.html後述しますが、Twitter等でのリリースアナウンスの際はここで用意したアナウンス文の要約を使用します。Hat系、Windows向け、ソースコードそれぞれにおいてパッケージやアーカイブのアップロードを行います。Debian系のパッケージのアップロードには以下のコマンドを実行します。Hat系のパッケージのアップロードには以下のコマンドを実行します。uploadWindows向けのパッケージのアップロードには以下のコマンドを実行します。uploadソースアーカイブのアップロードには以下のコマンドを実行します。uploadアップロードが正常終了すると、リリース対象のリポジトリデータやパッケージ、アーカイブ等がpackages.groonga.orgへと反映されます。Ubuntu用パッケージのアップロード¶Ubuntu向けパッケージの作成には、作業マシン上にGroongaのビルドに必要な依存ソフトウェア一式がインストールされている必要があります。以下のようにしてインストールしておいて下さい。groongaUbuntu向けのパッケージのアップロードには以下のコマンドを実行します。upload現在サポートされているのは以下の通りです。i386/amd64アップロードが正常終了すると、launchpad.net上でビルドが実行され、ビルド結果がメールで通知されます。ビルドに成功すると、リリース対象のパッケージがlaunchpad.netのGroongaチームのPPAへと反映されます。公開されているパッケージは以下のURLで確認できます。packages」リンクを辿ると、アップロード済みパッケージを削除できる。例;[不安定版リポジトリのパッケージの削除用のページ](https://launchpad.net/~groonga/+archive/ubuntu/nightly/+delete-packages)。公開されているリリース案内を作成します。基本的にはリリースアナウンスの内容をそのまま記載します。cloneしたWebサイトのソースに対して以下のファイルを新規追加します。interpreter(therubyracer、Node.jsなど)が必要です。インストールするには以下のコマンドを実行します。therubyracerjekyllのインストールを行ったら、以下のコマンドでローカルにwebサーバを起動します。--watchあとはブラウザにてhttp://localhost:4000にアクセスして内容に問題がないかを確認します。記事を非公開の状態でアップロードするには.mdファイルのpublished:をfalseに設定します。ドキュメントのアップロード¶doc/source以下のドキュメントを更新、翻訳まで完了している状態で、ドキュメントのアップロード作業を行います。リポジトリをカレントディレクトリにして以下のコマンドを実行します。DOCUMENT_VERSION_FULL=$GROONGA_VERSIONここでは最新のtagに基づいてリリースバージョンを調べ、明示的にそのバージョンを指定してドキュメントを更新するようにしています。これによりcloneしておいたgroonga.orgのdoc/locale以下に更新したドキュメントがコピーされます。生成されているドキュメントに問題のないことを確認できたら、コミット、pushしてgroonga.orgへと反映します。最新リリースのバージョン番号と日付を表す情報の指定があるので、これらも更新します。Homebrewの更新¶この手順は省略可能です(Homebrewの更新はGroongaプロジェクト本体のリリース要件には含まれません)。requestを送ります。https://github.com/Homebrew/homebrew-coreすでにGroongaのFormulaは取り込まれているので、リリースのたびにFormulaの内容を更新する作業を実施します。requestを送りました。https://github.com/mxcl/homebrew/pull/21456/files上記URLを参照するとわかるようにソースアーカイブのurlとsha1チェックサムを更新します。作成したリリースアナウンスをメーリングリストへと流します。Twitterでリリースアナウンスをする¶blogroongaのリリースエントリには「リンクをあなたのフォロワーに共有する」ためのツイートボタンがあるので、そのボタンを使ってリリースアナウンスします。2.0.8リリース」など)とblogroongaのリリースエントリのURLが挿入されます。この作業はblogroongaの英語版、日本語版それぞれで行います。groongaアカウントでログインしておくとアナウンスを円滑に行うことができます。Facebookでリリースアナウンスをする¶FacebookにGroongaグループがあります。https://www.facebook.com/groonga/Groongaグループのメンバーになると、個人のアカウントではなく、Groongaグループのメンバーとして投稿できます。ブログエントリなどをもとに、リリースアナウンスを投稿します。以上でリリース作業は終了です。リリース後にやること¶リリースアナウンスを流し終えたら、次期バージョンの開発が始まります。バージョン更新¶$GROONGA_CLONE_DIRにて以下のコマンドを実行します。NEW_VERSION=2.0.6これにより$GROONGA_CLONE_DIR/base_versionが更新されるのでコミットしておきます。注釈base_versionはtar.gzなどのリリース用のファイル名で使用します。特定の環境向けのみビルドしたい¶Debian系の場合、CODES,ARCHITECTURESオプションを明示的に指定することで、特定のリリース、アーキテクチャのみビルドすることができます。squeezeのi386のみビルドしたい場合には以下のコマンドを実行します。build-repository-debなどのサブタスクでもARCHITECTURES,CODES指定は有効です。Hat系の場合、ARCHITECTURES,DISTRIBUTIONSオプションを明示的に指定することで、特定のリリース、アーキテクチャのみビルドすることができます。fedoraのi386のみビルドしたい場合には以下のコマンドを実行します。build-repository-rpmなどのサブタスクでもARCHITECTURES,DISTRIBUTIONSの指定は有効です。centosの場合、CENTOS_VERSIONSを指定することで特定のバージョンのみビルドすることができます。リリース担当者向けの秘密鍵を復号したテキストの1行目に記載してあります。