12.3.7. リリース手順 — Groonga v16.1.0 documentation

Skip to main content
`Ctrl`+`K`

# 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` の実行

Run `rake release` to release a new version:

    $ cd ${GROONGA_CLONE_DIR}
    $ rake release

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

1. `release:version:update`

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

   You can change release date by `NEW_RELEASE_DATE`.

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` のようにバージョンを指定して更新できます。

Note

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. 各種テストの確認

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

- GitHub Actions

- Launchpad

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

### 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で確認できます。

> https://launchpad.net/~groonga/+archive/ubuntu/ppa

#### 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` は以下の通り更新されます。

- `pkgver` : 指定した最新のGroongaバージョン

- `pkgrel` : `1`

- `sha256sums` : 最新の https://packages.groonga.org/source/groonga/groonga-xx.x.x.tar.gz のsha256sum

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

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

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

> msys2/MINGW-packages#14320

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

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

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

    $ cd ${GROONGA_ORG_PATH}
    $ rake release

### 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を使う人へアピールする点や既存のバージョンを利用している人がアップグレードする際に必要な情報を提供します。

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

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

- [Groonga-talk] [ANN] Groonga 2.0.2

  > - http://sourceforge.net/mailarchive/message.php?msg_id=29195195

- [groonga-dev,00794] [ANN] Groonga 2.0.2

  > - http://osdn.jp/projects/groonga/lists/archive/dev/2012-April/000794.html

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

### 12.3.7.3.14. Homebrewの更新

この手順は省略可能です（Homebrewの更新はGroongaプロジェクト本体のリリース要件には含まれません）。

OS Xでのパッケージ管理方法として Homebrew があります。

Groongaを簡単にインストールできるようにするために、Homebrewへpull requestを送ります。

> Homebrew/homebrew-core

すでにGroongaのFormulaは取り込まれているので、リリースのたびにFormulaの内容を更新する作業を実施します。

Groonga 3.0.6のときは以下のように更新してpull requestを送りました。

> mxcl/homebrew#files

上記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グループのメンバーとして投稿できます。 ブログエントリなどをもとに、リリースアナウンスを投稿します。

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