Masafumi Yokoyama
null+****@clear*****
Fri Apr 24 16:57:18 JST 2015
Masafumi Yokoyama 2015-04-24 16:57:18 +0900 (Fri, 24 Apr 2015) New Revision: 79dbdf8f8bf65d95bb3025616bef7b339d34431f https://github.com/groonga/groonga/commit/79dbdf8f8bf65d95bb3025616bef7b339d34431f Message: doc release: improve markup Modified files: doc/source/contribution/development/release.rst Modified: doc/source/contribution/development/release.rst (+43 -43) =================================================================== --- doc/source/contribution/development/release.rst 2015-04-24 16:34:14 +0900 (57d6391) +++ doc/source/contribution/development/release.rst 2015-04-24 16:57:18 +0900 (1ff1945) @@ -3,10 +3,10 @@ .. highlightlang:: none リリース手順 -============================================================ +============ 前提条件 ------------------------------------------------------------- +-------- リリース手順の前提条件は以下の通りです。 @@ -22,7 +22,7 @@ * CUTTER_SOURCE_PATH=$HOME/work/cutter/cutter ビルド環境の準備 ------------------------------------------------------------- +---------------- 以下にGroongaのリリース作業を行うために事前にインストール しておくべきパッケージを示します。 @@ -46,7 +46,7 @@ Vagrantで使用する仮想化ソフトウェア（VirtualBox、VMwareなど） % sudo gem install rake パッケージ署名用秘密鍵のインポート ------------------------------------------------------------- +---------------------------------- リリース作業ではRPMパッケージに対する署名を行います。 その際、パッケージ署名用の鍵が必要です。 @@ -80,7 +80,7 @@ Groongaプロジェクトでは署名用の鍵をリリース担当者の公開 この作業は、新規にリリースを行うことになった担当者やパッケージに署名する鍵に変更があった場合などに行います。 リリース作業用ディレクトリの作成 ------------------------------------------------------------- +-------------------------------- Groongaのリリース作業ではリリース専用の環境下(コンパイルフラグ)でビルドする必要があります。 @@ -95,7 +95,7 @@ Groongaのリリース作業ではリリース専用の環境下(コンパイル この作業はリリース作業ごとに行います。 変更点のまとめ --------------------------- +-------------- 前回リリース時からの変更点を$GROONGA_CLONE_DIR/doc/source/news.txtにまとめます。 ここでまとめた内容についてはリリースアナウンスにも使用します。 @@ -117,7 +117,7 @@ Groongaのリリース作業ではリリース専用の環境下(コンパイル Groongaのウェブサイトの取得 ------------------------------------------------------------- +--------------------------- GroongaのウェブサイトのソースはGroonga同様にgithubにリポジトリを置いています。 @@ -130,7 +130,7 @@ Groongaのウェブサイトのソースコードを$GROONGA_ORG_PATHとして これで、$GROONGA_ORG_PATHにgroonga.orgのソースを取得できます。 cutterのソースコード取得 ------------------------------------------------------------- +------------------------ Groongaのリリース作業では、cutterに含まれるスクリプトを使用しています。 @@ -141,7 +141,7 @@ Groongaのリリース作業では、cutterに含まれるスクリプトを使 これで、$CUTTER_SOURCE_PATHディレクトリにcutterのソースを取得できます。 configureスクリプトの生成 ------------------------------------------------------------- +------------------------- Groongaのソースコードをcloneした時点ではconfigureスクリプトが含まれておらず、そのままmakeコマンドにてビルドすることができません。 @@ -152,7 +152,7 @@ $GROONGA_CLONE_DIRにてautogen.shを以下のように実行します。:: このコマンドの実行により、configureスクリプトが生成されます。 configureスクリプトの実行 ------------------------------------------------------------- +------------------------- Makefileを生成するためにconfigureスクリプトを実行します。 @@ -192,7 +192,7 @@ configureオプションである--with-cutter-source-pathにはcutterのソー make update-latest-releaseの実行 ------------------------------------------------------------- +-------------------------------- make update-latest-releaseコマンドでは、OLD_RELEASE_DATEに前回のリリースの日付を、NEW_RELEASE_DATEに次回リリースの日付を指定します。 @@ -204,7 +204,7 @@ make update-latest-releaseコマンドでは、OLD_RELEASE_DATEに前回のリ これにより、clone済みのGroongaのWebサイトのトップページのソース(index.html,ja/index.html)やRPMパッケージのspecファイルのバージョン表記などが更新されます。 make update-filesの実行 ------------------------------------------------------------- +----------------------- ロケールメッセージの更新や変更されたファイルのリスト等を更新するために以下のコマンドを実行します。:: @@ -215,7 +215,7 @@ make update-filesを実行すると新規に追加されたファイルなどが リリースに必要なファイルですので漏れなくコミットします。 make update-poの実行 ------------------------------------------------------------- +-------------------- ドキュメントの最新版と各国語版の内容を同期するために、poファイルの更新を以下のコマンドにて実行します。:: @@ -224,7 +224,7 @@ make update-poの実行 make update-poを実行すると、doc/locale/ja/LC_MESSAGES以下の各種.poファイルが更新されます。 poファイルの翻訳 ------------------------------------------------------------- +---------------- make update-poコマンドの実行により更新した各種.poファイルを翻訳します。 @@ -236,14 +236,14 @@ make update-poコマンドの実行により更新した各種.poファイルを 確認が完了したら、翻訳済みpoファイルをコミットします。 リリースタグの設定 ------------------------------------------------------------- +------------------ リリース用のタグを打つには以下のコマンドを実行します。:: % make tag リリース用アーカイブファイルの作成 ------------------------------------------------------------- +---------------------------------- リリース用のソースアーカイブファイルを作成するために以下のコマンドを$GROONGA_CLONE_DIRにて実行します。:: @@ -257,7 +257,7 @@ make update-poコマンドの実行により更新した各種.poファイルを make distで生成したtar.gzのversionおよびversion.shがタグと一致することを確認するのが望ましいです。 パッケージのビルド ------------------------------------------------------------- +------------------ リリース用のアーカイブファイルができたので、パッケージ化する作業を行います。 @@ -270,7 +270,7 @@ make update-poコマンドの実行により更新した各種.poファイルを パッケージのビルドではいくつかのサブタスクから構成されています。 ビルド用パッケージのダウンロード -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ debパッケージのビルドに必要なパッケージをダウンロードするには以下のコマンドを実行します。:: @@ -303,7 +303,7 @@ packages/source/filesディレクトリ以下へとダウンロードされま Debian系パッケージのビルド ------------------------------------------------------------- +-------------------------- Groongaのpackages/aptサブディレクトリに移動して、以下のコマンドを実行します。:: @@ -338,7 +338,7 @@ make build ではまとめてビルドできないこともあります。 Red Hat系パッケージのビルド ------------------------------------------------------------- +--------------------------- Groongaのpackages/yumサブディレクトリに移動して、以下のコマンドを実行します。:: @@ -372,7 +372,7 @@ make build PALALLEL=yesコマンドを実行すると、ディストリビュー Windows用パッケージのビルド ------------------------------------------------------------- +--------------------------- packages/windowsサブディレクトリに移動して、以下のコマンドを実行します。:: @@ -391,7 +391,7 @@ make packageが正常に終了するとzipアーカイブをfilesディレクト make installerが正常に終了するとWindowsインストーラをfilesディレクトリ以下に作成します。 パッケージの動作確認 ------------------------------------------------------------- +-------------------- ビルドしたパッケージに対しリリース前の動作確認を行います。 @@ -403,7 +403,7 @@ Debian系もしくはRed Hat系の場合には本番環境へとアップロー % ruby -run -e httpd -- packages/apt/repositories (aptの場合) grntestの準備 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~ grntestを実行するためにはGroongaのテストデータとgrntestのソースが必要です。 @@ -418,7 +418,7 @@ grntestを実行するためにはGroongaのテストデータとgrntestのソ README.md binlib license test grntestの実行方法 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~ grntestではGroongaコマンドを明示的にしていすることができます。 後述のパッケージごとのgrntestによる動作確認では以下のようにして実行します。:: @@ -434,7 +434,7 @@ grntestでエラーが発生しないことを確認します。 Debian系の場合 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~ Debian系の場合の動作確認手順は以下の通りとなります。 @@ -450,7 +450,7 @@ Debian系の場合の動作確認手順は以下の通りとなります。 Red Hat系の場合 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~ Red Hat系の場合の動作確認手順は以下の通りとなります。 @@ -463,7 +463,7 @@ Red Hat系の場合の動作確認手順は以下の通りとなります。 Windows向けの場合 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~ * 新規インストール/上書きインストールを行う * grntestのアーカイブを展開してインストールしたバージョンでテストを実行する @@ -472,7 +472,7 @@ Windows向けの場合 zipアーカイブも同様にしてgrntestを実行し動作確認を行います。 リリースアナウンスの作成 ------------------------------------------------------------- +------------------------ リリースの際にはリリースアナウンスを流して、Groongaを広く通知します。 @@ -501,7 +501,7 @@ news.txtに変更点をまとめましたが、それを元にリリースアナ パッケージのアップロード ------------------------------------------------------------- +------------------------ 動作確認が完了し、Debian系、Red Hat系、Windows向け、ソースコードそれぞれにおいてパッケージやアーカイブのアップロードを行います。 @@ -528,7 +528,7 @@ Windows向けのパッケージのアップロードには以下のコマンド アップロードが正常終了すると、リリース対象のリポジトリデータやパッケージ、アーカイブ等がpackages.groonga.orgへと反映されます。 Ubuntu用パッケージのアップロード ------------------------------------------------------------- +-------------------------------- Ubuntu向けのパッケージのアップロードには以下のコマンドを実行します。:: @@ -540,7 +540,7 @@ Ubuntu向けのパッケージのアップロードには以下のコマンド https://launchpad.net/~groonga/+archive/ubuntu/ppa blogroonga(ブログ)の更新 ------------------------------------------------------------- +------------------------ http://groonga.org/blog/ および http://groonga.org/blog/ にて公開されているリリース案内を作成します。 @@ -574,7 +574,7 @@ jekyllのインストールを行ったら、以下のコマンドでローカ ドキュメントのアップロード ------------------------------------------------------------- +-------------------------- doc/source以下のドキュメントを更新、翻訳まで完了している状態で、ドキュメントのアップロード作業を行います。 @@ -587,7 +587,7 @@ doc/source以下のドキュメントを更新、翻訳まで完了している 生成されているドキュメントに問題のないことを確認できたら、コミット、pushしてgroonga.orgへと反映します。 Homebrewの更新 ------------------------------------------------------------- +-------------- OS Xでのパッケージ管理方法として `Homebrew <http://brew.sh/>`_ があります。 @@ -604,7 +604,7 @@ Groonga 3.0.6のときは以下のように更新してpull requestを送りま 上記URLを参照するとわかるようにソースアーカイブのurlとsha1チェックサムを更新します。 リリースアナウンス ------------------------------------------------------------- +------------------ 作成したリリースアナウンスをメーリングリストへと流します。 @@ -612,7 +612,7 @@ Groonga 3.0.6のときは以下のように更新してpull requestを送りま * Groonga-talk groonga-talk �� lists.sourceforge.net Twitterでリリースアナウンスをする ------------------------------------------------------------- +--------------------------------- blogroongaのリリースエントリには「リンクをあなたのフォロワーに共有する」ためのツイートボタンがあるので、そのボタンを使ってリリースアナウンスします。(画面下部に配置されている) @@ -624,7 +624,7 @@ blogroongaのリリースエントリには「リンクをあなたのフォロ 以上でリリース作業は終了です。 リリース後にやること ------------------------------------------------------------- +-------------------- リリースアナウンスを流し終えたら、次期バージョンの開発が始まります。 @@ -632,12 +632,12 @@ blogroongaのリリースエントリには「リンクをあなたのフォロ * Groonga のbase_versionの更新 Groonga プロジェクトの新規バージョン追加 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ `Groonga プロジェクトの設定ページ <http://redmine.groonga.org/projects/groonga/settings>`_ にて新規バージョンを追加します。(例: release-2.0.6) Groonga バージョン更新 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~ $GROONGA_CLONE_DIRにて以下のコマンドを実行します。:: @@ -650,17 +650,17 @@ $GROONGA_CLONE_DIRにて以下のコマンドを実行します。:: ビルド時のTIPS ------------------------------------------------------------- +-------------- ビルドを並列化したい -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~ make build PALALLEL=yesを指定するとchroot環境で並列にビルドを 実行できます。 特定の環境向けのみビルドしたい -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Debian系の場合、CODES,ARCHITECTURESオプションを明示的に指定することで、特定のリリース、アーキテクチャのみビルドすることができます。 @@ -682,14 +682,14 @@ centosの場合、CENTOS_VERSIONSを指定することで特定のバージョ パッケージの署名用のパスフレーズを知りたい -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ パッケージの署名に必要な秘密鍵のパスフレーズについては リリース担当者向けの秘密鍵を復号したテキストの1行目に記載してあります。 バージョンを明示的に指定してドキュメントを生成したい -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ リリース後にドキュメントの一部を差し替えたい場合、特に何も指定しないと生成したHTMLに埋め込まれるバージョンが「v3.0.1-xxxxxドキュメント」となってしまうことがあります。gitでのコミット時ハッシュの一部が使われるためです。 -------------- next part -------------- HTML����������������������������...Download