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

  • APACHE_ARROW_REPOSITORY=$HOME/work/apache/arrow

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

また、rubyのrakeパッケージを以下のコマンドによりインストールします。

$ sudo gem install rake

12.3.7.2.2. PPA用の鍵の登録#

この作業は、新規にリリースを行うことになった担当者のみ行います。

[Launchpad](https://launchpad.net/)にアカウントを作成し、自分の普段使いの公開鍵を登録した上で、他のリリース担当者に依頼して[Groongaチーム](https://launchpad.net/~groonga)に追加してもらって下さい。

12.3.7.2.3. リリース作業用ディレクトリの作成#

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にリポジトリを置いています。

リリース作業では後述するコマンド( rake release:version:update )でタグをプッシュしてCIが動き出すトリガーとします。

$ git clone git@github.com:groonga/groonga.org.git ${GROONGA_ORG_PATH}

これで、$GROONGA_ORG_PATHにgroonga.orgのソースを取得できます。

12.3.7.3.3. Apache Arrowリポジトリの取得#

Apache Arrowのソースも取得します。Apache ArrowのRakeタスクを利用するためです。

$ git clone https://github.com/apache/arrow.git ${APACHE_ARROW_REPOSITORY}

12.3.7.3.4. 事前確認#

Ubuntu向けパッケージをテスト用に公開する時は、 Ubuntu向けパッケージのビルド確認 の手順で不安定版のリポジトリにアップロードするように指定します。

新任のリリース担当者は必ず、この方法でPPAのリポジトリにパッケージをアップロードできる事を確認しておいてください。

PPAのリポジトリは、同名のパッケージを上書いてアップロードできないので、不安定版のリポジトリでビルドできることを確認してから、安定版のリポジトリへアップロードするようにしてください。

12.3.7.3.5. 変更点のまとめ#

前回リリース時からの変更点を $GROONGA_CLONE_DIR/doc/source/news/*.md （英語）にまとめます。 ここでまとめた内容についてはリリースアナウンスにも使用します。

前回リリースからの変更履歴を参照するには以下のコマンドを実行します。

$ git log -p --reverse $(git tag --sort=taggerdate | tail -1)..

ログを^commitで検索しながら、以下の基準を目安として変更点を追記していきます。

含めるもの

  • ユーザへ影響するような変更

  • 互換性がなくなるような変更

含めないもの

  • 内部的な変更(変数名の変更やらリファクタリング)

12.3.7.3.6. rake release の実行#

rake release コマンドでは、 NEW_RELEASE_DATE にリリースの日付（≒ 実行日）を指定します。

$ cd ${GROONGA_CLONE_DIR}
$ rake release NEW_RELEASE_DATE=$(date +%Y-%m-%d)

release タスクは次の3つのタスクを実行します。

  1. release:version:update

    • RPMパッケージのspecファイルに新しいバージョンのチェンジログを追記したりなどします。

  2. release:tag

    • リリース用のタグを打ちます。

    • これによりタグがプッシュされ自動リリースが動き出します。

  3. dev:version:bump

    • 次のリリースに向けてバージョンを更新します。

12.3.7.3.6.1. 補足: dev:version:bump タスク#

rake dev:version:bump NEW_VERSION=x.x.x のようにバージョンを指定して更新できます。

注釈

base_versionはtar.gzなどのリリース用のファイル名で使用します。

12.3.7.3.7. Ubuntu向けパッケージのビルド確認#

Ubuntu向けのパッケージは、Launchpadでビルドしています。 リリース前にUbuntu向けパッケージが正常にビルドできるか以下の手順で確認します。

rake release:version:update の結果をリポジトリーにpush後にGitHub Actionsで生成されるソースアーカイブをダウンロードします。 ダウンロードしたソースアーカイブを $GROONGA_CLONE_DIR のトップに配置します。その後、以下のコマンドを実行してください。

$ cd $GROONGA_CLONE_DIR/packages
$ rake ubuntu DPUT_CONFIGURATION_NAME=groonga-ppa-nightly DPUT_INCOMING="~groonga/ubuntu/nightly" LAUNCHPAD_UPLOADER_PGP_KEY=xxxxxxx

12.3.7.3.8. 各種テストの確認#

リリース用のタグを設定する前に、以下のテストが全てパスしているかを確認します。 タグを設定してから問題が発覚すると、再度リリースすることになってしまうので、タグを設定する前に問題がないか確認します。

テストやパッケージの作成に失敗していたら、原因を特定して修正します。

12.3.7.3.9. Ubuntu用パッケージのアップロード#

Ubuntu向けパッケージの作成には、作業マシン上にGroongaのビルドに必要な依存ソフトウェア一式がインストールされている必要があります。以下のようにしてインストールしておいて下さい。

$ sudo apt build-dep groonga

Ubuntu向けのパッケージのアップロードには以下のコマンドを実行します。

$ cd packages
$ rake ubuntu LAUNCHPAD_UPLOADER_PGP_KEY=xxxxxxx

アップロードが正常終了すると、launchpad.net上でビルドが実行され、ビルド結果がメールで通知されます。ビルドに成功すると、リリース対象のパッケージがlaunchpad.netのGroongaチームのPPAへと反映されます。公開されているパッケージは以下のURLで確認できます。

12.3.7.3.9.1. Ubuntu用パッケージの公開の取り消し#

LaunchpadのGroongaチームのページで対象のPPAを選択し、バージョン一覧の上にある「View package details」リンクの先で「Delete packages」リンクを辿ると、アップロード済みパッケージを削除できます。 例；[不安定版リポジトリのパッケージの削除用のページ](https://launchpad.net/~groonga/+archive/ubuntu/nightly/+delete-packages)。

12.3.7.3.10. WindowsのMSYS2用パッケージのアップロード#

MINGW-packages の、 mingw-w64-groonga/PKGBUILD を最新にして、プルリクエストを作成します。

MINGW-packagesはforkして自分のリポジトリを作成しておきます。 また、forkしたリポジトリのGitHub Actionsを有効にしておきます。

forkしたリポジトリをローカルにcloneし、upstreamに本家のMINGW-packagesを登録しておきます。この作業は一度だけ行います。

$ mkdir -p ~/work
$ git clone --recursive git@github.com:<your-forked-MINGW-packages>.git ~/work/MINGW-packages
$ git remote add upstream https://github.com/msys2/MINGW-packages.git

以下の手順で必要なファイルの更新と、プルリクエスト用のブランチの作成をします。 12.0.9 は最新のGroongaのバージョンを指定します。

$ cd ~/work/groonga/groonga.clean/packages
$ ./post-msys2.sh 12.0.9 $HOME/work/MINGW-packages

post-msys2.sh スクリプトは以下の処理を実行します。

  • forkしたリポジトリの更新（ master ブランチを本家のリポジトリの master にrebase）

  • master ブランチから groonga-12.0.9 ブランチの作成

  • mingw-w64-groonga/PKGBUILD の更新

  • forkしたリポジトリに groonga-12.0.9 ブランチをpush

このとき、 mingw-w64-groonga/PKGBUILD は以下の通り更新されます。

forkしたリポジトリにて、pushされたブランチのGitHub Actionsが成功していることを確認します。 これで正しくビルドできているかどうかが確認できます。

確認後、本家のMINGW-packagesにプルリクエストを作成します。

過去のプルリクエストの例は以下です。

プルリクエストがマージされると、MSYS2用のパッケージがリリースされます。

12.3.7.3.11. ドキュメントの更新#

groonga.org リポジトリにて次のタスクを実行します。そうすることでタグがプッシュされCIにてドキュメントが更新されます。

$ cd ${GROONGA_ORG_PATH}
$ rake release:version:update

12.3.7.3.12. Dockerイメージの更新#

Docker Hub のGroongaのDockerイメージを更新します。

GroongaのDockerリポジトリー をクローンし、リポジトリーの中のDockerfileを更新します。

以下は、Groongaのバージョンが 12.0.9 の場合の例です。作業時には最新のバージョンを指定してください。

$ mkdir -p ~/work/groonga
$ rm -rf ~/work/groonga/docker.clean
$ git clone --recursive git@github.com:groonga/docker.git ~/work/groonga/docker.clean
$ cd ~/work/groonga/docker.clean
$ ./update.sh 12.0.9 #Automatically update Dockerfiles and commit changes and create a tag.
$ git push

GroongaのDockerリポジトリーのGithub Actions が成功しているのを確認してから、タグをpushします。

$ git push --tags

pushすると、 GroongaのDockerリポジトリーのGithub Actions が Docker HubのGroonga のDockerイメージを自動で更新します。

12.3.7.3.13. リリースアナウンスの作成#

リリースの際にはリリースアナウンスを流して、Groongaを広く通知します。

news.rstに変更点をまとめましたが、それを元にリリースアナウンスを作成します。

リリースアナウンスには以下を含めます。

  • インストール方法へのリンク

  • リリースのトピック紹介

  • リリース変更点へのリンク

  • リリース変更点(news.rstの内容)

リリースのトピック紹介では、これからGroongaを使う人へアピールする点や既存のバージョンを利用している人がアップグレードする際に必要な情報を提供します。

非互換な変更が含まれるのであれば、回避方法等の案内を載せることも重要です。

参考までに過去のリリースアナウンスへのリンクを以下に示します。

後述しますが、Twitter等でのリリースアナウンスの際はここで用意したアナウンス文の要約を使用します。

12.3.7.3.14. 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.15. Twitterでリリースアナウンスをする#

BloGroongaのリリースエントリには「リンクをあなたのフォロワーに共有する」ためのツイートボタンがあるので、そのボタンを使ってリリースアナウンスします。(画面下部に配置されている)

このボタンを経由する場合、ツイート内容に自動的にリリースタイトル(「groonga 2.0.8リリース」など)とBloGroongaのリリースエントリのURLが挿入されます。

この作業はBloGroongaの英語版、日本語版それぞれで行います。 あらかじめgroongaアカウントでログインしておくとアナウンスを円滑に行うことができます。

12.3.7.3.16. Facebookでリリースアナウンスをする#

FacebookにGroongaグループがあります。 https://www.facebook.com/groonga/

Groongaグループのメンバーになると、個人のアカウントではなく、Groongaグループのメンバーとして投稿できます。 ブログエントリなどをもとに、リリースアナウンスを投稿します。

以上でリリース作業は終了です。