以下にgroongaのリリース作業を行うために事前にインストール しておくべきパッケージを示します。
なお、ビルド環境としては Ubuntu 12.04 LTS(Precise Pangolin)を前提とし て説明しています。その他の環境では適宜読み替えて下さい。:
% sudo apt-get install -V debootstrap rinse createrepo rpm
mercurial python-sphinx ruby1.9.1-full mingw-w64 g++-mingw-w64 mecab libmecab-dev nsis gnupg2
rinseのバージョンが古いとCentOS 5/6パッケージのビルドを行うことができ ません。 別途debパッケージを以下のコマンドを実行して最新版をインストールしま す。:
% sudo dpkg -i rinse_1.9.2-1_all.deb
また、rubyのrakeパッケージを以下のコマンドによりインストールします。:
% sudo gem1.9.1 install rake
なお、特に明記していない限り本リリース手順でのコマンドラインの 操作はzshを前提としています。
groongaのリリース作業ではリリース専用の環境下(コンパイルフラグ)でビルド する必要があります。
リリース時と開発時でディレクトリを分けずに作業することもできますが、 誤ったコンパイルフラグでリリースしてしまう危険があります。
そのため、以降の説明では$(HOME)/work/groonga以下のディレクトリに リリース用の作業ディレクトリ(groonga.clean)にソースコードを cloneしたものとして説明します。
リリース用のクリーンな状態でソースコードをgroonga.cleanディレ クトリに取得するために以下のコマンドを実行します。:
% git clone git@github.com:groonga/groonga.git groonga.clean
この作業は初回のリリース作業のときに必要です。
リリース作業ではRPMパッケージに対する署名を行います。 その際、パッケージ署名用の鍵が必要です。
groongaプロジェクトでは署名用の鍵をリリース担当者の公開鍵で 暗号化してリポジトリのpackages/ディレクトリ以下へと登録しています。
リリース担当者はリポジトリに登録された秘密鍵を復号した後に 鍵のインポートを以下のコマンドにて行います。:
% cd packages
% gpg --decrypt release-key-secret.asc.gpg.(担当者) > (復号した鍵
ファイル)
% gpg --import (復号した鍵ファイル)
鍵のインポートが正常終了すると gpg --list-keys でgroongaの署名用の 鍵を確認することができます。:
pub 1024R/F10399C0 2012-04-24
uid groonga Key (groonga Official Signing Key)
<packages@groonga.org>
sub 1024R/BC009774 2012-04-24
鍵をインポートしただけでは使用することができないため、インポートした鍵 に対してtrust,signを行う必要があります。
以下のコマンドを実行して署名を行います。(途中の選択肢は省略):
% gpg --edit-key packages@groonga.org
gpg> trust
gpg> sign
gpg> save
gpg> quit
前回リリース時からの変更点をdoc/source/news.txtにまとめます。 ここでまとめた内容についてはリリースアナウンスにも使用します。
前回リリースからの変更履歴を参照するには以下のコマンドを実行します。:
% git log -p --reverse $(git tag | tail -1)..
ログを^commitで検索しながら、以下の基準を目安として変更点を追記してい きます。
含めるもの
含めないもの
groongaのウェブサイトのソースはgroonga同様にgithubにリポジトリを置いて います。
リリース作業では後述するコマンド(make update-latest-release)にてトップページのバージョンを 置き換えることができるようになっています。
groongaのウェブサイトのソースコードは以下コマンドにてのように取得します。:
% git clone git@github.com:groonga/groonga.github.com.git
これで、~/work/groonga/groonga.github.comにソースを取得できます。
ソースコードをcloneした時点ではconfigureスクリプトが含まれておらず そのままmakeコマンドにてビルドすることができません。
groongaのリリース作業ディレクトリでautogen.shを以下のように実行します。:
% sh autogen.sh
このコマンドの実行により、configureスクリプトが生成されます。
Makefileを生成するためにconfigureスクリプトを実行します。
リリース用にビルドするためには以下のオプションを指定してconfigureを実行し ます。:
% ./configure CFLAGS="-O0 -ggdb3" CXXFLAGS="-O0 -ggdb3" --prefix=/tmp/local --with-rsync-path="packages@packages.groonga.org:public" --with-groonga-github-com-path=$HOME/work/groonga/groonga.github.com --enable-document --with-ruby19
configureオプションである--with-groonga-github-com-pathにはgroongaのウェ ブサイトのリポジトリをcloneした場所を指定します。
以下のようにgroongaのソースコードをcloneした先からの相対パスを指定することもできます。:
% ./configure CFLAGS="-O0 -ggdb3" CXXFLAGS="-O0 -ggdb3" --prefix=/tmp/local --with-rsync-path="packages@packages.groonga.org:public" --with-groonga-github-com-path=../groonga.github.com --enable-document --with-ruby19
あらかじめpackagesユーザでpackages.groonga.orgにsshログインできることを 確認しておいてください。
ログイン可能であるかの確認は以下のようにコマンドを実行して行います。:
% ssh packages@packages.groonga.org
make update-latest-releaseコマンドでは、 OLD_RELEASE_DATEに前回のリリースの日付を、NEW_RELEASE_DATEに次回リリー スの日付を指定します。
2.0.2のリリースを行った際は以下のコマンドを実行しました。::
% make update-latest-release OLD_RELEASE=2.0.1 OLD_RELEASE_DATE=2012-03-29 NEW_RELEASE_DATE=2012-04-29
これにより、clone済みのgroongaのWebサイトのトップページのソース (index.html,ja/index.html)やRPMパッケージのspecファイルのバージョン表記などが更新されます。
ノート
このとき更新されるspecファイルは現在リリースする人の名前が固定となっているのでリリース作業後にカスタマイズ指定可能なように修正を入れる
ロケールメッセージの更新や変更されたファイルのリスト等を更新するために 以下のコマンドを実行します。(このコマンドを実行するにはあらかじめ sphinxのインストールが必要です。):
% make update-files
make update-filesを実行すると新規に追加されたファイルなどが 各種.amファイルへとリストアップされます。
リリースに必要なファイルですので漏れなくコミットします。
ドキュメントの最新版と各国語版の内容を同期するために、 poファイルの更新を以下のコマンドにて実行します。:
% make update-po
make update-poを実行すると、doc/locale/ja/LC_MESSAGES以下の各種.poファ イルが更新されます。
make update-poコマンドの実行により更新した各種.poファイルを翻訳します。
翻訳結果をHTMLで確認するために、以下のコマンドを実行します。:
% make -C doc/locale/ja html
% make -C doc/locale/en html
確認が完了したら、翻訳済みpoファイルをコミットします。
リリース用のソースアーカイブファイルを作成するために 以下のコマンドをgroonga.clean直下で実行します。:
% make dist
これによりgroonga.clean/groonga-(バージョン).tar.gzが作成されます。
リリース用のアーカイブファイルができたので、 パッケージ化する作業を行います。
パッケージ化作業は以下の3種類を対象に行います。
パッケージのビルドではいくつかのサブタスクから構成されています。
debパッケージのビルドに必要なパッケージをダウンロードするには 以下のコマンドを実行します。:
% cd packages/apt
% make download
これにより、lucid以降の関連する.debパッケージやソースアーカイブなどがカ レントディレクトリ以下へとダウンロードされます。
rpmパッケージのビルドに必要なパッケージをダウンロードするには 以下のコマンドを実行します。:
% cd packages/yum
% make download
これにより、groongaやMySQLのRPM/SRPMパッケージなどがカレントディレクト リ以下へとダウンロードされます。
windowsパッケージのビルドに必要なパッケージをダウンロードするには 以下のコマンドを実行します。:
% cd packages/windows
% make download
これにより、groongaのインストーラやzipアーカイブがカレントディレクトリ 以下へとダウンロードされます。
sourceパッケージに必要なものをダウンロードするには以下のコマンドを 実行します。:
% cd packages/source
% make download
これにより過去にリリースしたソースアーカイブ(.tar.gz)が packages/source/filesディレクトリ以下へとダウンロードされます。
groongaのpackages/aptサブディレクトリに移動して、以下のコマンドを実行します。:
% cd packages/apt
% make build PALALLEL=yes
make build PALALLEL=yesコマンドを実行すると、ディストリビューションの リリースとアーキテクチャの組み合わせでビルドを平行して行うことができま す。
現在サポートされているのは以下の通りです。
ノート
unstable i386/amd64はpreciseに構築したchroot環境ではパッケージのビ ルドが行えることを確認できていないことに注意。
正常にビルドが終了すると以下のディレクトリへと.debパッケージが生成され ます。
make build ですんなりビルドできないこともあります。 その場合にはbuildのサブタスクであるbuild-package-debと build-repository-debを個別に実行して問題が発生している箇所を切り分ける 必要があります。
生成したパッケージへの署名を行うには以下のコマンドを実行します。:
% make sign-packages
リリース対象のファイルをリポジトリに反映するには以下のコマンドを実行します。:
% make update-repository
リポジトリにGnuPGで署名を行うために以下のコマンドを実行します。:
% make sign-repository
groongaのpackages/yumサブディレクトリに移動して、以下のコマンドを実行します。:
% cd packages/yum
% make build PALALLES=yes
make build PALALLEL=yesコマンドを実行すると、ディストリビューションの リリースとアーキテクチャの組み合わせでビルドを平行して行うことができま す。
現在サポートされているのは以下の通りです。
ビルドが正常終了すると以下のディレクトリにRPMが生成されます。
リポジトリを作成するには以下のコマンドを実行します。:
% make build
リリース対象のRPMに署名を行うには以下のコマンドを実行します。:
% make sign
リリース対象のファイルをリポジトリに反映するには以下のコマンドを実行します。:
% make update
packages/windowsサブディレクトリに移動して、以下のコマンドを実行します。:
% cd packages/windows
% make build
% make package
% make installer
make releaseを実行することでbuildからuploadまで一気に実行することがで きますが、途中で失敗することもあるので順に実行することをおすすめします。
make buildでクロスコンパイルを行います。 正常に終了するとdist-x64/dist-x86ディレクトリ以下にx64/x86バイナリを作成します。
make packageが正常に終了するとzipアーカイブをfilesディレクトリ以下に作成します。
make installerが正常に終了するとWindowsインストーラをfilesディレクトリ以 下に作成します。
ビルドしたパッケージに対しリリース前の動作確認を行います。
Debian系もしくはRed Hat系の場合には本番環境へとアップロードする前に ローカルのaptないしyumのリポジトリを参照して正常に更新できることを 確認します。
ここでは以下のようにrubyを利用してリポジトリをwebサーバ経由で 参照できるようにします。:
% ruby1.9.1 -run -e httpd -- packages/yum/repositories (yumの場合)
% ruby1.9.1 -run -e httpd -- packages/apt/repositories (aptの場合)
grntestを実行するためにはgroongaのテストデータとgrntestのソースが 必要です。
まずgroongaのソースを任意のディレクトリへと展開します。:
% tar zxvf groonga-(バージョン).tar.gz
次にgroongaのtest/functionディレクトリ以下にgrntestのソースを展開します。 つまりtest/function/grntestという名前でgrntestのソースを配置します。:
% ls test/function/grntest/
README.md binlib license test
grntestではgroongaコマンドを明示的にしていすることができます。 後述のパッケージごとのgrntestによる動作確認では以下のようにして 実行します。:
% GROONGA=(groongaのパス指定) test/function/run-test.sh
最後にgrntestによる実行結果が以下のようにまとめて表示されます。:
55 tests, 52 passes, 0 failures, 3 not checked tests.
94.55% passed.
grntestでエラーが発生しないことを確認します。
Debian系の場合の動作確認手順は以下の通りとなります。
Red Hat系の場合の動作確認手順は以下の通りとなります。
zipアーカイブも同様にしてgrntestを実行し動作確認を行います。
リリースの際にはリリースアナウンスを流して、 groongaを広く通知します。
news.txtに変更点をまとめましたが、それを元にリリースアナウンスを 作成します。
リリースアナウンスには以下を含めます。
リリースのトピック紹介では、これからgroongaを使う人へアピールする点や 既存のバージョンを利用している人がアップグレードする際に必要な 情報を提供します。
非互換な変更が含まれるのであれば、回避方法等の案内を載せることも重要で す。
参考までに過去のリリースアナウンスへのリンクを以下に示します。
[Groonga-talk] [ANN] groonga 2.0.2
[groonga-dev,00794] [ANN] groonga 2.0.2
動作確認が完了し、Debian系、Red Hat系、Windows向け、ソースコードそ れぞれにおいてパッケージやアーカイブのアップロードを行います。
Debian系のパッケージのアップロードには以下のコマンドを実行します。:
% cd packages/apt
% make upload
Red Hat系のパッケージのアップロードには以下のコマンドを実行します。:
% cd packages/yum
% make upload
Windows向けのパッケージのアップロードには以下のコマンドを実行します。:
% cd packages/windows
% make upload
ソースアーカイブのアップロードには以下のコマンドを実行します。:
% cd packages/source
% make upload
アップロードが正常終了すると、リリース対象のリポジトリデータやパッケージ、アーカイブ 等がpackages.groonga.orgへと反映されます。
http://groonga.org/blog/ および http://groonga.org/blog/ にて 公開されているリリース案内を作成します。
基本的にはリリースアナウンスの内容をそのまま記載します。
cloneしたWebサイトのソースに対して以下のファイルを新規追加します。
編集した内容をpushする前に確認したい場合にはjekyllおよび RedClothが必要です。 インストールするには以下のコマンドを実行します。:
% sudo gem1.9.1 install jekyll RedCloth
jekyllのインストールを行ったら、以下のコマンドでローカルにwebサーバを 起動します。:
% jekyll --server --auto
あとはブラウザにてhttp://localhost:4000にアクセスして内容に問題がない かを確認します。
doc/source以下のドキュメントを更新、翻訳まで完了している状態で、 ドキュメントのアップロード作業を行います。
そのためにはまず以下のコマンドを実行します。:
% make update-document
これによりcloneしておいたgroonga.github.comのdoc/locale以下に更新した ドキュメントがコピーされます。
生成されているドキュメントに問題のないことを確認できたら、 コミット、pushしてgroonga.orgへと反映します。
作成したリリースアナウンスをメーリングリストへと流します。
以上でリリース作業は終了です。
make build PALALLES=yesを指定するとchroot環境で並列にビルドを 実行できます。
Debian系の場合、CODES,ARCHITECTURESオプションを明示的に指定することで、 特定のリリース、アーキテクチャのみビルドすることができます。
squeezeのi386のみビルドしたい場合には以下のコマンドを実行します。:
% make build ARCHITECTURES=i386 CODES=squeeze
buildコマンド以外でも build-package-deb build-repository-debなどの サブタスクでもARCHITECTURES,CODES指定は有効です。
Red Hat系の場合、ARCHITECTURES,DISTRIBUTIONSオプションを明示的に指定す ることで、特定のリリース、アーキテクチャのみビルドすることができます。
fedoraのi386のみビルドしたい場合には以下のコマンドを実行します。:
% make build ARCHITECTURES=i386 DISTRIBUTIONS=fedora
buildコマンド以外でも build-in-chroot build-repository-rpmなどの サブタスクでもARCHITECTURES,DISTRIBUTIONSの指定は有効です。
ただし、centosの場合 バージョンまで明示して5のみビルドや6のみビルド することはできません。まとめてcentosとしてビルドされます。
パッケージの署名に必要な秘密鍵のパスフレーズについては リリース担当者向けの秘密鍵を復号したテキストの1行目に記載してあります。