.. -*- rst -*-

.. highlightlang:: none

リリース手順
============================================================

前提条件
------------------------------------------------------------

リリース手順の前提条件は以下の通りです。

* ビルド環境は Ubuntu 12.04 LTS(Precise Pangolin)
* コマンドラインの実行例はzsh

作業ディレクトリ例は以下を使用します。

* GROONGA_DIR=$HOME/work/groonga
* GROONGA_CLONE_DIR=$HOME/work/groonga/groonga.clean
* GROONGA_GITHUB_COM_PATH=$HOME/work/groonga/groonga.github.com
* CUTTER_DIR=$HOME/work/cutter
* CUTTER_SOURCE_PATH=$HOME/work/cutter/cutter

ビルド環境の準備
------------------------------------------------------------

以下にgroongaのリリース作業を行うために事前にインストール
しておくべきパッケージを示します。

なお、ビルド環境としては Ubuntu 12.04 LTS(Precise Pangolin)を前提として説明しているため、その他の環境では適宜読み替えて下さい。::

    % sudo apt-get install -V debootstrap rinse createrepo rpm
    mercurial python-docutils python-jinja2 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

パッケージ署名用秘密鍵のインポート
------------------------------------------------------------

リリース作業では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
    
この作業は、新規にリリースを行うことになった担当者やパッケージに署名する鍵に変更があった場合などに行います。

リリース作業用ディレクトリの作成
------------------------------------------------------------

groongaのリリース作業ではリリース専用の環境下(コンパイルフラグ)でビルドする必要があります。

リリース時と開発時でディレクトリを分けずに作業することもできますが、誤ったコンパイルフラグでリリースしてしまう危険があります。

そのため、以降の説明では$GROONGA_DIR以下のディレクトリにリリース用の作業ディレクトリ(groonga.clean)としてソースコードをcloneしたものとして説明します。

リリース用のクリーンな状態でソースコードを取得するために$GROONGA_DIRにて以下のコマンドを実行します。::

    % git clone git@github.com:groonga/groonga.git groonga.clean

この作業はリリース作業ごとに行います。

変更点のまとめ
--------------------------

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

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

   % git log -p --reverse $(git tag | tail -1)..

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

含めるもの

* ユーザへ影響するような変更
* 互換性がなくなるような変更

含めないもの

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


groongaのウェブサイトの取得
------------------------------------------------------------

groongaのウェブサイトのソースはgroonga同様にgithubにリポジトリを置いています。

リリース作業では後述するコマンド(make update-latest-release)にてトップページのバージョンを置き換えることができるようになっています。

groongaのウェブサイトのソースコードを$GROONGA_GITHUB_COM_PATHとして取得するためには、$GROONGA_DIRにて以下のコマンドを実行します。::

    % git clone git@github.com:groonga/groonga.github.com.git

これで、$GROONGA_GITHUB_COM_PATHにgroonga.github.comのソースを取得できます。

cutterのソースコード取得
------------------------------------------------------------

groongaのリリース作業では、cutterに含まれるスクリプトを使用しています。

そこであらかじめ用意しておいた$HOME/work/cutterディレクトリにてcutterのソースコードを以下のコマンドにて取得します。::

    % git clone git@github.com:clear-code/cutter.git

これで、$CUTTER_SOURCE_PATHディレクトリにcutterのソースを取得できます。

configureスクリプトの生成
------------------------------------------------------------

groongaのソースコードをcloneした時点ではconfigureスクリプトが含まれておらず、そのままmakeコマンドにてビルドすることができません。

$GROONGA_CLONE_DIRにてautogen.shを以下のように実行します。::

    % sh autogen.sh

このコマンドの実行により、configureスクリプトが生成されます。

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 --with-cutter-source-path=$HOME/work/cutter/cutter 

configureオプションである--with-groonga-github-com-pathにはgroongaのウェブサイトのリポジトリをcloneした場所を指定します。

configureオプションである--with-cutter-source-pathにはcutterのソースを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 --with-cutter-source-path=../../cutter/cutter 

あらかじめpackagesユーザでpackages.groonga.orgにsshログインできることを確認しておいてください。

ログイン可能であるかの確認は以下のようにコマンドを実行して行います。::

    % ssh packages@packages.groonga.org


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ファイルのバージョン表記などが更新されます。

make update-filesの実行
------------------------------------------------------------

ロケールメッセージの更新や変更されたファイルのリスト等を更新するために以下のコマンドを実行します。::

    % make update-files

make update-filesを実行すると新規に追加されたファイルなどが各種.amファイルへとリストアップされます。

リリースに必要なファイルですので漏れなくコミットします。

make update-poの実行
------------------------------------------------------------

ドキュメントの最新版と各国語版の内容を同期するために、poファイルの更新を以下のコマンドにて実行します。::

    % make update-po

make update-poを実行すると、doc/locale/ja/LC_MESSAGES以下の各種.poファイルが更新されます。

poファイルの翻訳
------------------------------------------------------------

make update-poコマンドの実行により更新した各種.poファイルを翻訳します。

翻訳結果をHTMLで確認するために、以下のコマンドを実行します。::

    % make -C doc/locale/ja html
    % make -C doc/locale/en html

確認が完了したら、翻訳済みpoファイルをコミットします。

リリースタグの設定
------------------------------------------------------------

リリース用のタグを打つには以下のコマンドを実行します。::

    % make tag

リリース用アーカイブファイルの作成
------------------------------------------------------------

リリース用のソースアーカイブファイルを作成するために以下のコマンドを$GROONGA_CLONE_DIRにて実行します。::

    % make dist

これにより$GROONGA_CLONE_DIR/groonga-(バージョン).tar.gzが作成されます。

.. note::
   タグを打つ前にmake distを行うとversionが古いままになることがあります。
   するとgroonga --versionで表示されるバージョン表記が更新されないので注意が必要です。
   make distで生成したtar.gzのversionおよびversion.shがタグと一致することを確認するのが望ましいです。

パッケージのビルド
------------------------------------------------------------

リリース用のアーカイブファイルができたので、パッケージ化する作業を行います。

パッケージ化作業は以下の3種類を対象に行います。

* Debianç³»(.deb)
* Red Hatç³»(.rpm)
* Windowsç³»(.exe,.zip)

パッケージのビルドではいくつかのサブタスクから構成されています。

ビルド用パッケージのダウンロード
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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ディレクトリ以下へとダウンロードされます。


Debian系パッケージのビルド
------------------------------------------------------------

groongaのpackages/aptサブディレクトリに移動して、以下のコマンドを実行します。::

    % cd packages/apt
    % make build PALALLEL=yes

make build PALALLEL=yesコマンドを実行すると、ディストリビューションのリリースとアーキテクチャの組み合わせでビルドを平行して行うことができます。

現在サポートされているのは以下の通りです。

* squeeze i386/amd64
* wheezy i386/amd64
* unstable i386/amd64
* lucid i386/amd64
* natty i386/amd64
* oneiric i386/amd64
* precise i386/amd64
* quantal i386/amd64

正常にビルドが終了すると$GROONGA_CLONE_DIR/packages/apt/repositories配下に.debパッケージが生成されます。

make build ではまとめてビルドできないこともあります。
その場合にはディストリビューションごとやアーキテクチャごとなど、個別にビルドすることで問題が発生している箇所を切り分ける必要があります。

生成したパッケージへの署名を行うには以下のコマンドを実行します。::

    % make sign-packages

リリース対象のファイルをリポジトリに反映するには以下のコマンドを実行します。::

    % make update-repository

リポジトリにGnuPGで署名を行うために以下のコマンドを実行します。::

    % make sign-repository


Red Hat系パッケージのビルド
------------------------------------------------------------

groongaのpackages/yumサブディレクトリに移動して、以下のコマンドを実行します。::

    % cd packages/yum
    % make build PALALLES=yes

make build PALALLEL=yesコマンドを実行すると、ディストリビューションのリリースとアーキテクチャの組み合わせでビルドを平行して行うことができます。

現在サポートされているのは以下の通りです。

* centos-5 i386/x86_64
* centos-6 i386/x86_64
* fedora-17 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/fedora/17/i386/Packages
* repositories/yum/fedora/17/x86_64/Packages

リリース対象のRPMに署名を行うには以下のコマンドを実行します。::

    % make sign-packages

リリース対象のファイルをリポジトリに反映するには以下のコマンドを実行します。::

    % make update-repository


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ディレクトリ以下に作成します。

パッケージの動作確認
------------------------------------------------------------

ビルドしたパッケージに対しリリース前の動作確認を行います。

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の準備
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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の実行方法
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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系の場合
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Debian系の場合の動作確認手順は以下の通りとなります。

* 旧バージョンをchroot環境へとインストールする
* chroot環境の/etc/hostsを書き換えてpackages.groonga.orgがホストを
  参照するように変更する
* ホストでwebサーバを起動してドキュメントルートをビルド環境のもの
  (repositories/apt/packages)に設定する
* アップグレード手順を実行する
* grntestのアーカイブを展開してインストールしたバージョンでテストを実
  行する
* grntestの正常終了を確認する


Red Hat系の場合
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Red Hat系の場合の動作確認手順は以下の通りとなります。

* 旧バージョンをchroot環境へとインストール
* chroot環境の/etc/hostsを書き換えてpackages.groonga.orgがホストを参照するように変更する
* ホストでwebサーバを起動してドキュメントルートをビルド環境のもの(packages/yum/repositories)に設定する
* アップグレード手順を実行する
* grntestのアーカイブを展開してインストールしたバージョンでテストを実行する
* grntestの正常終了を確認する


Windows向けの場合
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

* 新規インストール/上書きインストールを行う
* grntestのアーカイブを展開してインストールしたバージョンでテストを実行する
* grntestの正常終了を確認する

zipアーカイブも同様にしてgrntestを実行し動作確認を行います。

リリースアナウンスの作成
------------------------------------------------------------

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

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

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

* インストール方法へのリンク
* リリースのトピック紹介
* リリース変更点へのリンク
* リリース変更点(news.txtの内容)

リリースのトピック紹介では、これから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://sourceforge.jp/projects/groonga/lists/archive/dev/2012-April/000794.html


パッケージのアップロード
------------------------------------------------------------

動作確認が完了し、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へと反映されます。

blogroonga(ブログ)の更新
------------------------------------------------------------

http://groonga.org/blog/ および http://groonga.org/blog/ にて公開されているリリース案内を作成します。

基本的にはリリースアナウンスの内容をそのまま記載します。

cloneしたWebサイトのソースに対して以下のファイルを新規追加します。

* groonga.github.com/en/_post/(リリース日)-release.textile
* groonga.github.com/ja/_post/(リリース日)-release.textile


編集した内容をpushする前に確認したい場合にはjekyllおよびRedClothが必要です。
インストールするには以下のコマンドを実行します。::

    % sudo gem1.9.1 install jekyll RedCloth

jekyllのインストールを行ったら、以下のコマンドでローカルにwebサーバを起動します。::

    % jekyll serve --watch

あとはブラウザにてhttp://localhost:4000にアクセスして内容に問題がないかを確認します。

.. note::
   記事を非公開の状態でアップロードするには.textileファイルのpublished:をfalseに設定します。::

    ---
    layout: post.en
    title: Groonga 2.0.5 has been released
    published: false
    ---
    

ドキュメントのアップロード
------------------------------------------------------------

doc/source以下のドキュメントを更新、翻訳まで完了している状態で、ドキュメントのアップロード作業を行います。

そのためにはまず以下のコマンドを実行します。::

    % make update-document

これによりcloneしておいたgroonga.github.comのdoc/locale以下に更新したドキュメントがコピーされます。

生成されているドキュメントに問題のないことを確認できたら、コミット、pushしてgroonga.orgへと反映します。

リリースアナウンス
------------------------------------------------------------

作成したリリースアナウンスをメーリングリストへと流します。

* groonga-dev groonga-dev@lists.sourceforge.jp
* Groonga-talk groonga-talk@lists.sourceforge.net

freecode.comへリリース情報を登録
------------------------------------------------------------

groongaプロジェクトではfreecode.comでもリリース情報を発信しています。

freecode.comのプロジェクトページは以下の通りです。

  https://freecode.com/projects/groonga

プロジェクトの管理メニューから「Submit a release」をクリックし、
新規リリース情報を登録します。

  https://freecode.com/projects/groonga/releases/new

.. note::
   投稿した内容に対するレビューが運営側で実施されるので、反映されるまでしばらく時間がかかります。

Twitterでリリースアナウンスをする
------------------------------------------------------------

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

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

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

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

リリース後にやること
------------------------------------------------------------

リリースアナウンスを流し終えたら、次期バージョンの開発が始まります。

* groonga プロジェクトの新規バージョン追加
* groonga のbase_versionの更新

groonga プロジェクトの新規バージョン追加
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

`groonga プロジェクトの設定ページ <http://redmine.groonga.org/projects/groonga/settings>`_ にて新規バージョンを追加します。(例: release-2.0.6)

groonga バージョン更新
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

$GROONGA_CLONE_DIRにて以下のコマンドを実行します。::

    % make update-version NEW_VERSION=2.0.6

これにより$GROONGA_CLONE_DIR/base_versionが更新されるのでコミットしておきます。

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


ビルド時のTIPS
------------------------------------------------------------

ビルドを並列化したい
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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の場合、CENTOS_VERSIONSを指定することで特定のバージョンのみビルドすることができます。


パッケージの署名用のパスフレーズを知りたい
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

パッケージの署名に必要な秘密鍵のパスフレーズについては
リリース担当者向けの秘密鍵を復号したテキストの1行目に記載してあります。


バージョンを明示的に指定してドキュメントを生成したい
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

リリース後にドキュメントの一部を差し替えたい場合、特に何も指定しないと生成したHTMLに埋め込まれるバージョンが「v3.0.1-xxxxxドキュメント」となってしまうことがあります。gitでのコミット時ハッシュの一部が使われるためです。

これを回避するには、以下のようにDOCUMENT_VERSIONやDOCUMENT_VERSION_FULLを明示的に指定します。::

    % make update-document DOCUMENT_VERSION=3.0.1 DOCUMENT_VERSION_FULL=3.0.1