12.3.7. リリース手順¶
12.3.7.1. 前提条件¶
リリース手順の前提条件は以下の通りです。
ビルド環境は Debian GNU/Linux (sid)
コマンドラインの実行例はzsh
作業ディレクトリ例は以下を使用します。
GROONGA_DIR=$HOME/work/groonga
GROONGA_CLONE_DIR=$HOME/work/groonga/groonga.clean
GROONGA_ORG_PATH=$HOME/work/groonga/groonga.org
CUTTER_DIR=$HOME/work/cutter
CUTTER_SOURCE_PATH=$HOME/work/cutter/cutter
12.3.7.2. 最初の1回だけ行う手順¶
12.3.7.2.1. ビルド環境の準備¶
以下にGroongaのリリース作業を行うために事前にインストール しておくべきパッケージを示します。
なお、ビルド環境としては Debian GNU/Linux (sid)を前提として説明しているため、その他の環境では適宜読み替えて下さい。:
% sudo apt-get install -V debootstrap createrepo rpm mercurial python-docutils python-jinja2 ruby-full mingw-w64 g++-mingw-w64 mecab libmecab-dev nsis gnupg2 dh-autoreconf bison
また、Sphinxは常に最新のバージョンを使う事を推奨します。 pip
を使用して最新のSphinxをインストールするようにして下さい。:
% pip install --upgrade sphinx
Debian系(.deb)やRed Hat系(.rpm)パッケージのビルドには Vagrant を使用します。apt-getでインストールできるのは古いバージョンなので、Webサイトから最新版をダウンロードしてインストールすることをおすすめします。
Vagrantで使用する仮想化ソフトウェア(VirtualBox、VMwareなど)がない場合、合わせてインストールしてください。なお、VirtualBoxはsources.listにcontribセクションを追加すればapt-getでインストールできます。:
% cat /etc/apt/sources.list
deb http://ftp.jp.debian.org/debian/ sid main contrib
deb-src http://ftp.jp.debian.org/debian/ sid main contrib
% sudo apt-get update
% sudo apt-get install virtualbox
また、rubyのrakeパッケージを以下のコマンドによりインストールします。:
% sudo gem install rake
12.3.7.2.2. パッケージ署名用秘密鍵のインポート¶
リリース作業では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
この作業は、新規にリリースを行うことになった担当者やパッケージに署名する鍵に変更があった場合などに行います。
12.3.7.2.3. PPA用の鍵の登録¶
この作業は、新規にリリースを行うことになった担当者のみ行います。
[Launchpad](https://launchpad.net/)にアカウントを作成し、自分の普段使いの秘密鍵を登録した上で、他のリリース担当者に依頼して[Groongaチーム](https://launchpad.net/~groonga)に追加してもらって下さい。
12.3.7.2.4. リリース作業用ディレクトリの作成¶
Groongaのリリース作業ではリリース専用の環境下(コンパイルフラグ)でビルドする必要があります。
リリース時と開発時でディレクトリを分けずに作業することもできますが、誤ったコンパイルフラグでリリースしてしまう危険があります。
そのため、以降の説明では$GROONGA_DIR以下のディレクトリにリリース用の作業ディレクトリ(groonga.clean)としてソースコードをcloneしたものとして説明します。
12.3.7.3. 毎回のリリースで行う手順¶
12.3.7.3.1. Groongaのソースコード取得¶
リリース用のクリーンな状態でソースコードを取得するために$GROONGA_DIRにて以下のコマンドを実行します。:
% git clone --recursive git@github.com:groonga/groonga.git groonga.clean
この作業はリリース作業ごとに行います。
12.3.7.3.2. Groongaのウェブサイトの取得¶
GroongaのウェブサイトのソースはGroonga同様にgithubにリポジトリを置いています。
リリース作業では後述するコマンド(make update-latest-release)にてトップページのバージョンを置き換えることができるようになっています。
Groongaのウェブサイトのソースコードを$GROONGA_ORG_PATHとして取得するためには、$GROONGA_DIRにて以下のコマンドを実行します。:
% git clone git@github.com:groonga/groonga.org.git
これで、$GROONGA_ORG_PATHにgroonga.orgのソースを取得できます。
12.3.7.3.3. cutterのソースコード取得¶
Groongaのリリース作業では、cutterに含まれるスクリプトを使用しています。
そこであらかじめ用意しておいた$HOME/work/cutterディレクトリにてcutterのソースコードを以下のコマンドにて取得します。:
% git clone git@github.com:clear-code/cutter.git
これで、$CUTTER_SOURCE_PATHディレクトリにcutterのソースを取得できます。
12.3.7.3.4. 変更点のまとめ¶
前回リリース時からの変更点を$GROONGA_CLONE_DIR/doc/source/news.rst(英語)にまとめます。 ここでまとめた内容についてはリリースアナウンスにも使用します。
前回リリースからの変更履歴を参照するには以下のコマンドを実行します。:
% git log -p --reverse $(git tag | tail -1)..
ログを^commitで検索しながら、以下の基準を目安として変更点を追記していきます。
含めるもの
ユーザへ影響するような変更
互換性がなくなるような変更
含めないもの
内部的な変更(変数名の変更やらリファクタリング)
具体的な変更点の記述方法は後述します。
12.3.7.3.5. configureスクリプトの生成¶
Groongaのソースコードをcloneした時点ではconfigureスクリプトが含まれておらず、そのままmakeコマンドにてビルドすることができません。
$GROONGA_CLONE_DIRにてautogen.shを以下のように実行します。:
% sh autogen.sh
このコマンドの実行により、configureスクリプトが生成されます。
12.3.7.3.6. configureスクリプトの実行¶
Makefileを生成するためにconfigureスクリプトを実行します。
リリース用にビルドするためには以下のオプションを指定してconfigureを実行します。:
% ./configure \
--prefix=/tmp/local \
--with-launchpad-uploader-pgp-key=(Launchpadに登録したkeyID) \
--with-groonga-org-path=$HOME/work/groonga/groonga.org \
--enable-document \
--with-ruby \
--enable-mruby \
--with-cutter-source-path=$HOME/work/cutter/cutter
configureオプションである–with-groonga-org-pathにはGroongaのウェブサイトのリポジトリをcloneした場所を指定します。
configureオプションである–with-cutter-source-pathにはcutterのソースをcloneした場所を指定します。
以下のようにGroongaのソースコードをcloneした先からの相対パスを指定することもできます。:
% ./configure \
--prefix=/tmp/local \
--with-launchpad-uploader-pgp-key=(Launchpadに登録したkeyID) \
--with-groonga-org-path=../groonga.org \
--enable-document \
--with-ruby \
--enable-mruby \
--with-cutter-source-path=../../cutter/cutter
あらかじめpackagesユーザでpackages.groonga.orgにsshログインできることを確認しておいてください。
ログイン可能であるかの確認は以下のようにコマンドを実行して行います。:
% ssh packages@packages.groonga.org
デバッグ用や開発用のパッケージをテスト用に公開する時は、 --with-launchpad-ppa=groonga-nightly
を指定して不安定版のリポジトリにアップロードするように指定します。:
% ./configure \
--with-launchpad-ppa=groonga-nightly \
--prefix=/tmp/local \
--with-launchpad-uploader-pgp-key=(Launchpadに登録したkeyID) \
--with-groonga-org-path=$HOME/work/groonga/groonga.org \
--enable-document \
--with-ruby \
--enable-mruby \
--with-cutter-source-path=$HOME/work/cutter/cutter
新任のリリース担当者は必ず、この方法でPPAのリポジトリにパッケージをアップロードできる事を確認しておいてください。
12.3.7.3.7. make update-latest-releaseの実行¶
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ファイルのバージョン表記などが更新されます。
12.3.7.3.8. make update-examplesの実行¶
ドキュメントに埋め込まれている実行結果を更新するために、以下のコマンドを実行します。:
% cd doc && make update-examples
doc/source/examples以下が更新されるので、それらをコミットします。
12.3.7.3.9. make update-filesの実行¶
ロケールメッセージの更新や変更されたファイルのリスト等を更新するために以下のコマンドを実行します。:
% make update-files
make update-filesを実行すると新規に追加されたファイルなどが各種.amファイルへとリストアップされます。
リリースに必要なファイルですので漏れなくコミットします。
12.3.7.3.10. make update-poの実行¶
ドキュメントの最新版と各国語版の内容を同期するために、poファイルの更新を以下のコマンドにて実行します。:
% make update-po
make update-poを実行すると、doc/locale/ja/LC_MESSAGES以下の各種.poファイルが更新されます。
12.3.7.3.11. poファイルの翻訳¶
make update-poコマンドの実行により更新した各種.poファイルを翻訳します。
翻訳結果をHTMLで確認するために、以下のコマンドを実行します。:
% make -C doc/locale/ja html
% make -C doc/locale/en html
修正が必要な箇所を調べて、 ***.edit
というファイルを適宜修正します。:
% cd groonga/doc/locale
% git diff
***.edit
というファイルの編集中は、翻訳元のファイルは絶対に編集しないで下さい(編集すると、***.edit
に加えた変更が make update-po の実行時に失われます)。
ファイルを編集したら、再度poファイルとHTMLを更新するために以下のコマンドを実行します。:
% make update-po
% make -C doc/locale/ja html
% make -C doc/locale/en html
確認が完了したら、翻訳済みpoファイルをコミットします。
12.3.7.3.12. リリースタグの設定¶
リリース用のタグを打つには以下のコマンドを実行します。:
% make tag
Note
タグを打った後にconfigureを実行することで、ドキュメント生成時のバージョン番号に反映されます。
12.3.7.3.13. リリース用アーカイブファイルの作成¶
リリース用のソースアーカイブファイルを作成するために以下のコマンドを$GROONGA_CLONE_DIRにて実行します。:
% make dist
これにより$GROONGA_CLONE_DIR/groonga-(バージョン).tar.gzが作成されます。
Note
タグを打つ前にmake distを行うとversionが古いままになることがあります。 するとgroonga –versionで表示されるバージョン表記が更新されないので注意が必要です。 make distで生成したtar.gzのversionおよびversion.shがタグと一致することを確認するのが望ましいです。
12.3.7.3.14. パッケージのビルド¶
リリース用のアーカイブファイルができたので、パッケージ化する作業を行います。
パッケージ化作業は以下の3種類を対象に行います。
Debian系(.deb)
Red Hat系(.rpm)
Windows系(.exe,.zip)
パッケージのビルドではいくつかのサブタスクから構成されています。
12.3.7.3.14.1. ビルド用パッケージのダウンロード¶
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ディレクトリ以下へとダウンロードされます。
12.3.7.3.15. Debian系パッケージのビルド¶
Groongaのpackages/aptサブディレクトリに移動して、以下のコマンドを実行します。:
% cd packages/apt
% make build PARALLEL=yes
make build PARALLEL=yesコマンドを実行すると、ディストリビューションのリリースとアーキテクチャの組み合わせでビルドを平行して行うことができます。ホストマシンの性能に複数台のVMを動作させるだけの余裕がない場合は、PARALLEL=yesは指定しないで下さい。その場合、各アーキテクチャ向けのビルドが順番に行われます。
現在サポートされているのは以下の通りです。
Debian GNU/Linux
jessie i386/amd64
正常にビルドが終了すると$GROONGA_CLONE_DIR/packages/apt/repositories配下に.debパッケージが生成されます。
make build ではまとめてビルドできないこともあります。 その場合にはディストリビューションごとやアーキテクチャごとなど、個別にビルドすることで問題が発生している箇所を切り分ける必要があります。
生成したパッケージへの署名を行うには以下のコマンドを実行します。:
% make sign-packages
リリース対象のファイルをリポジトリに反映するには以下のコマンドを実行します。:
% make update-repository
リポジトリにGnuPGで署名を行うために以下のコマンドを実行します。:
% make sign-repository
12.3.7.3.16. Red Hat系パッケージのビルド¶
Groongaのpackages/yumサブディレクトリに移動して、以下のコマンドを実行します。:
% cd packages/yum
% make build PARALLEL=yes
make build PARALLEL=yesコマンドを実行すると、ディストリビューションのリリースとアーキテクチャの組み合わせでビルドを平行して行うことができます。
現在サポートされているのは以下の通りです。
centos-5 i386/x86_64
centos-6 i386/x86_64
centos-7 i386/x86_64
ビルドが正常終了すると$GROONGA_CLONE_DIR/packages/yum/repositories配下にRPMパッケージが生成されます。
repositories/yum/centos/5/i386/Packages
repositories/yum/centos/5/x86_64/Packages
repositories/yum/centos/6/i386/Packages
repositories/yum/centos/6/x86_64/Packages
repositories/yum/centos/7/i386/Packages
repositories/yum/centos/7/x86_64/Packages
リリース対象のRPMに署名を行うには以下のコマンドを実行します。:
% make sign-packages
リリース対象のファイルをリポジトリに反映するには以下のコマンドを実行します。:
% make update-repository
12.3.7.3.17. Windows用パッケージのビルド¶
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ディレクトリ以下に作成します。
12.3.7.3.18. パッケージの動作確認¶
ビルドしたパッケージに対しリリース前の動作確認を行います。
Debian系もしくはRed Hat系の場合には本番環境へとアップロードする前にローカルのaptないしyumのリポジトリを参照して正常に更新できることを確認します。
ここでは以下のようにrubyを利用してリポジトリをwebサーバ経由で参照できるようにします。
yumの場合:
% ruby -run -e httpd -- packages/yum/repositories
% yum update
...
aptの場合:
% ruby -run -e httpd -- packages/apt/repositories
% sudo apt update
...
12.3.7.3.18.1. grntestの準備¶
TravisCIの結果が正常であれば、この手順はスキップして構いません。 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
12.3.7.3.18.2. grntestの実行方法¶
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でエラーが発生しないことを確認します。
12.3.7.3.18.3. Debian系の場合¶
Debian系の場合の動作確認手順は以下の通りとなります。
旧バージョンをテスト環境へとインストールする
テスト環境の/etc/hostsを書き換えてpackages.groonga.orgがホストを 参照するように変更する
ホストでwebサーバを起動してドキュメントルートをビルド環境のもの (repositories/apt/packages)に設定する
アップグレード手順を実行する
grntestのアーカイブを展開してインストールしたバージョンでテストを実 行する
grntestの正常終了を確認する
12.3.7.3.18.4. Red Hat系の場合¶
Red Hat系の場合の動作確認手順は以下の通りとなります。
旧バージョンをテスト環境へとインストール
テスト環境の/etc/hostsを書き換えてpackages.groonga.orgがホストを参照するように変更する
ホストでwebサーバを起動してドキュメントルートをビルド環境のもの(packages/yum/repositories)に設定する
アップグレード手順を実行する
grntestのアーカイブを展開してインストールしたバージョンでテストを実行する
grntestの正常終了を確認する
12.3.7.3.18.5. Windows向けの場合¶
テスト環境で新規インストール/上書きインストールを行う
grntestのアーカイブを展開してインストールしたバージョンでテストを実行する
grntestの正常終了を確認する
zipアーカイブも同様にしてgrntestを実行し動作確認を行います。
12.3.7.3.19. リリースアナウンスの作成¶
リリースの際にはリリースアナウンスを流して、Groongaを広く通知します。
news.rstに変更点をまとめましたが、それを元にリリースアナウンスを作成します。
リリースアナウンスには以下を含めます。
インストール方法へのリンク
リリースのトピック紹介
リリース変更点へのリンク
リリース変更点(news.rstの内容)
リリースのトピック紹介では、これからGroongaを使う人へアピールする点や既存のバージョンを利用している人がアップグレードする際に必要な情報を提供します。
非互換な変更が含まれるのであれば、回避方法等の案内を載せることも重要です。
参考までに過去のリリースアナウンスへのリンクを以下に示します。
[Groonga-talk] [ANN] Groonga 2.0.2
[groonga-dev,00794] [ANN] Groonga 2.0.2
後述しますが、Twitter等でのリリースアナウンスの際はここで用意したアナウンス文の要約を使用します。
12.3.7.3.20. パッケージのアップロード¶
動作確認が完了し、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へと反映されます。
12.3.7.3.21. Ubuntu用パッケージのアップロード¶
Ubuntu向けパッケージの作成には、作業マシン上にGroongaのビルドに必要な依存ソフトウェア一式がインストールされている必要があります。以下のようにしてインストールしておいて下さい。:
% sudo apt build-dep groonga
Ubuntu向けのパッケージのアップロードには以下のコマンドを実行します。:
% cd packages/ubuntu
% make upload
現在サポートされているのは以下の通りです。
precise i386/amd64
trusty i386/amd64
vivid i386/amd64
アップロードが正常終了すると、launchpad.net上でビルドが実行され、ビルド結果がメールで通知されます。ビルドに成功すると、リリース対象のパッケージがlaunchpad.netのGroongaチームのPPAへと反映されます。公開されているパッケージは以下のURLで確認できます。
12.3.7.3.21.1. Ubuntu用パッケージの公開の取り消し¶
LaunchpadのGroongaチームのページで対象のPPAを選択し、バージョン一覧の上にある「View package details」リンクの先で「Delete packages」リンクを辿ると、アップロード済みパッケージを削除できる。 例;[不安定版リポジトリのパッケージの削除用のページ](https://launchpad.net/~groonga/+archive/ubuntu/nightly/+delete-packages)。
12.3.7.3.22. blogroonga(ブログ)の更新¶
http://groonga.org/blog/ および http://groonga.org/blog/ にて公開されているリリース案内を作成します。
基本的にはリリースアナウンスの内容をそのまま記載します。
cloneしたWebサイトのソースに対して以下のファイルを新規追加します。
groonga.org/en/_post/(リリース日)-release.md
groonga.org/ja/_post/(リリース日)-release.md
編集した内容をpushする前に確認したい場合にはJekyllおよびRedCloth(Textileパーサー)、RDiscount(Markdownパーサー)、JavaScript interpreter(therubyracer、Node.jsなど)が必要です。 インストールするには以下のコマンドを実行します。:
% sudo gem install jekyll jekyll-paginate RedCloth rdiscount therubyracer
jekyllのインストールを行ったら、以下のコマンドでローカルにwebサーバを起動します。:
% jekyll serve --watch
あとはブラウザにてhttp://localhost:4000にアクセスして内容に問題がないかを確認します。
Note
記事を非公開の状態でアップロードするには.mdファイルのpublished:をfalseに設定します。:
---
layout: post.en
title: Groonga 2.0.5 has been released
published: false
---
12.3.7.3.23. ドキュメントのアップロード¶
doc/source以下のドキュメントを更新、翻訳まで完了している状態で、ドキュメントのアップロード作業を行います。
そのためにはまず groonga
のリポジトリをカレントディレクトリにして以下のコマンドを実行します。:
% GROONGA_VERSION=$(git tag --list | tail -n 1 | tr -d v)
% make update-document DOCUMENT_VERSION=$GROONGA_VERSION DOCUMENT_VERSION_FULL=$GROONGA_VERSION
ここでは最新のtagに基づいてリリースバージョンを調べ、明示的にそのバージョンを指定してドキュメントを更新するようにしています。 これによりcloneしておいたgroonga.orgのdoc/locale以下に更新したドキュメントがコピーされます。
生成されているドキュメントに問題のないことを確認できたら、コミット、pushしてgroonga.orgへと反映します。
また、groonga.org
リポジトリの _config.yml
に最新リリースのバージョン番号と日付を表す情報の指定があるので、これらも更新します。:
groonga_version: x.x.x
groonga_release_date: xxxx-xx-xx
12.3.7.3.24. Homebrewの更新¶
この手順は省略可能です(Homebrewの更新はGroongaプロジェクト本体のリリース要件には含まれません)。
OS Xでのパッケージ管理方法として Homebrew があります。
Groongaを簡単にインストールできるようにするために、Homebrewへpull requestを送ります。
すでにGroongaのFormulaは取り込まれているので、リリースのたびにFormulaの内容を更新する作業を実施します。
Groonga 3.0.6のときは以下のように更新してpull requestを送りました。
上記URLを参照するとわかるようにソースアーカイブのurlとsha1チェックサムを更新します。
12.3.7.3.25. リリースアナウンス¶
作成したリリースアナウンスをメーリングリストへと流します。
groonga-dev groonga-dev@lists.osdn.me
Groonga-talk groonga-talk@lists.sourceforge.net
12.3.7.3.26. Twitterでリリースアナウンスをする¶
blogroongaのリリースエントリには「リンクをあなたのフォロワーに共有する」ためのツイートボタンがあるので、そのボタンを使ってリリースアナウンスします。(画面下部に配置されている)
このボタンを経由する場合、ツイート内容に自動的にリリースタイトル(「groonga 2.0.8リリース」など)とblogroongaのリリースエントリのURLが挿入されます。
この作業はblogroongaの英語版、日本語版それぞれで行います。 あらかじめgroongaアカウントでログインしておくとアナウンスを円滑に行うことができます。
12.3.7.3.27. Facebookでリリースアナウンスをする¶
FacebookにGroongaグループがあります。 https://www.facebook.com/groonga/
Groongaグループのメンバーになると、個人のアカウントではなく、Groongaグループのメンバーとして投稿できます。 ブログエントリなどをもとに、リリースアナウンスを投稿します。
以上でリリース作業は終了です。
12.3.7.3.28. リリース後にやること¶
リリースアナウンスを流し終えたら、次期バージョンの開発が始まります。
Groonga のbase_versionの更新
12.3.7.3.28.1. Groonga バージョン更新¶
$GROONGA_CLONE_DIRにて以下のコマンドを実行します。:
% make update-version NEW_VERSION=2.0.6
これにより$GROONGA_CLONE_DIR/base_versionが更新されるのでコミットしておきます。
Note
base_versionはtar.gzなどのリリース用のファイル名で使用します。
12.3.7.3.29. ビルド時のTIPS¶
12.3.7.3.29.1. ビルドを並列化したい¶
make build PARALLEL=yesを指定するとchroot環境で並列にビルドを 実行できます。
12.3.7.3.29.2. 特定の環境向けのみビルドしたい¶
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の場合、CENTOS_VERSIONSを指定することで特定のバージョンのみビルドすることができます。
12.3.7.3.29.3. パッケージの署名用のパスフレーズを知りたい¶
パッケージの署名に必要な秘密鍵のパスフレーズについては リリース担当者向けの秘密鍵を復号したテキストの1行目に記載してあります。