RubyGems - rroonga - Versions diffs - 7.0.2-x64-mingw32 → 7.1.1-x64-mingw32 - Mend

rroonga 7.0.2-x64-mingw32 → 7.1.1-x64-mingw32

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (1237) hide show

data/vendor/local/share/doc/groonga/en/html/_sources/contribution/development/build/windows_cmake.txt DELETED Viewed

@@ -1,93 +0,0 @@
-.. -*- rst -*-
-.. highlightlang:: none
-How to build Groonga at the repository by CMake on Windows
-==========================================================
-This document describes how to build Groonga at the repository by
-CMake on Windows.
-If you want to use GNU/Linux or Unix for developing Groonga, see
-:doc:`unix_cmake`.
-Unix is \*BSD, Solaris, OS X and so on.
-Install depended software
--------------------------
-  * `Microsoft Visual Studio Express 2013 for Windows Desktop
-    <https://www.visualstudio.com/downloads/#d-2013-express>`_
-  * `CMake <http://www.cmake.org/>`_
-  * `Ruby <https://www.ruby-lang.org/>`_
-    * `RubyInstaller for Windows <http://rubyinstaller.org/>`_ is
-      recommended.
-  * `Git <https://git-scm.com/>`_: There are some Git clients for
-    Windows. For example:
-    * `The official Git package <https://git-scm.com/download/win>`_
-    * `TortoiseGit <https://tortoisegit.org/>`_
-    * `Git for Windows <https://git-for-windows.github.io/>`_
-    * `GitHub Desktop <https://desktop.github.com/>`_
-Checkout Groonga from the repository
-------------------------------------
-Users use released source archive. But developers must build Groonga
-at the repository. Because source code in the repository is the
-latest.
-The Groonga repository is hosted on `GitHub
-<https://github.com/groonga/groonga>`_. Checkout the latest source
-code from the repository::
-  > git clone --recursive git@github.com:groonga/groonga.git
-Run ``cmake``
--------------
-You need to create ``Makefile`` for your environment.
-You can custom your build configuration by passing options to
-``cmake``.
-You must to pass ``-G`` option. Here are available ``-G`` value:
-  * ``"Visual Studio 12 2013"``: For 32bit build.
-  * ``"Visual Studio 12 2013 Win64"``: For 64bit build.
-Here are recommended ``cmake`` options for developers::
-  > cmake . -G "Visual Studio 12 2013 Win64" -DCMAKE_INSTALL_PREFIX=C:\Groonga -DGRN_WITH_MRUBY=on
-Here are descriptions of these options:
-``-G "Visual Studio 12 2013 Win64"``
-``-DCMAKE_INSTALL_PREFIX=C:\Groonga``
-    It specifies that you install your Groonga into ``C:\\Groonga``
-    folder.
-``-DGRN_WITH_MRUBY=on``
-    It enables mruby support. The feature isn't enabled by default
-    but developers should enable the feature.
-Build Groonga
--------------
-Now, you can build Groonga.
-You can use Visual Studio or ``cmake --build``.
-Here is a command line to build Groonga by ``cmake --build``::
-  > cmake --build . --config Debug
-See also
---------
-  * :doc:`/contribution/development/test`

data/vendor/local/share/doc/groonga/en/html/_sources/contribution/development/com.txt DELETED Viewed

@@ -1,20 +0,0 @@
-.. -*- rst -*-
-Groonga 通信アーキテクチャ
-==========================
-GQTPでのアーキテクチャ
-----------------------
-- comが外部からの接続を受け付ける。
-- comは1スレッド。
-- comがedgeを作る。
-- edgeは接続と１対１対応。
-- edgeはctxを含む。
-- workerはthreadと１対１対応。
-- workerは上限が個定数。
-- workerは、１つのedgeと結びつくことができる。
-- edgeごとにqueueを持つ。
-- msgはcomによって、edgeのqueueにenqueueされる。
-  edgeがworkerに結びついていないときは、同時に、ctx_newというqueueに、msgをenqueueした対象のedgeをenqueueする。

data/vendor/local/share/doc/groonga/en/html/_sources/contribution/development/cooperation.txt DELETED Viewed

@@ -1,75 +0,0 @@
-.. -*- rst -*-
-.. highlightlang:: none
-ユーザーと協力して開発をうまく進めていくための指針
-==================================================
-Groongaを使ってくれているユーザーと協力して
-開発をうまく進めていくためにこうするといい、という事柄をまとめました。
-まとめておくと、新しく開発に加わる人とも共有することができます。
-Twitter編
----------
-Groongaを使ってもらえるようにTwitterのアカウントGroongaを取得して
-日々、リリースの案内をしたり、ユーザーサポートをしたりしています。
-リリースの案内に利用する場合には、やりとりを考えなくて良いですが、
-複数人によるサポートをGroongaで行う場合に、どうサポートするのが
-良いのか/どうしてそうするのかという共通認識を持っていないと一貫性のないサポートとなってしま
-います。
-Twitterでサポートされている安心感からGroongaユーザーの拡大に繋げる
-ことができるようにサポートの際に気をつけることをまとめます。
-過去のツイートはおさらいしておく
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-理由
-....
-自分がツイートした内容を把握していない返信をされたら普通いい気はしません。
-対応
-....
-過去のツイートをおさらいし、こうすれば良いという提案をできるのが望ましいです。::
-    良い例: ○○だと原因は□□ですね。××すると大丈夫です。
-こちらから情報を提供する
-^^^^^^^^^^^^^^^^^^^^^^^^
-理由
-....
-困っているユーザーが複数回ツイートして限られたなかで情報を提供してくれていることがあります。
-その限られたツイートから解決方法が見つかればユーザーにとって余計な手間が少なくて済みます。
-あれこれ情報提供を要求すると、ユーザーはそのぶん確認する作業が必要になります。
-対応
-....
-最初に声をかけるときに解決策を1つか2つ提案できると望ましいです。ユーザーにあまり負担を感じさせないようにすると良いです。::
-    良い例: ○○の場合は□□の可能性があるので、××を試してもらえますか？
-Twitterでのやりとりはできるだけ他の場所(例えばRedmine)へと誘導しない
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-理由
-....
-Twitterは気軽につぶやけることが重要なので、気軽にできないことを相手に要求すると萎縮されてしまう可能性があります。
-いきなりRedmineでバグ報告をお願いすると、しりごみしてしまうかもしれません。::
-    駄目な例: 再現手順をMLかRedmineに報告してもらえますか?
-Groonga関連で気軽につぶやけないとなると開発者は困っている人を見つけられないし、利用者は困ったままとなるので、双方にとって嬉しくない状態になってしまいます。
-対応
-....
-Twitterでやりとりを完結できるようにします。

data/vendor/local/share/doc/groonga/en/html/_sources/contribution/development/query.txt DELETED Viewed

@@ -1,214 +0,0 @@
-.. -*- rst -*-
-.. highlightlang:: none
-クエリの実現
-============
-Groongaのデータベースには大量のデータを格納し、その中から必要な部分を高速に取り出すことができます。必要な部分をGroongaのデータベースに問い合わせるためのクエリの表現と実行に関して、Groongaは複数の手段を用意しています。
-クエリ実行のためのインタフェース
---------------------------------
-Groongaは低機能で単純なライブラリインタフェースから、高機能で複雑なコマンドインタフェースまでいくつかの階層的なインタフェースをユーザプログラムに提供しています。
-クエリ実行のためのインタフェースも階層的なインタフェースのそれぞれに対応する形で用意されています。以下に低レイヤなインタフェースから順に説明します。
-DB_API
-^^^^^^
-DB_APIは、Groongaデータベースを操作するための一群のC言語向けAPI関数を提供します。DB_APIはデータベースを構成する個々の部分に対する単純な操作関数を提供します。DB_APIの機能を組み合わせることによって複雑なクエリを実行することができます。後述のすべてのクエリインタフェースはDB_APIの機能を組み合わせることによって実現されています。
-grn_expr
-^^^^^^^^
-grn_exprは、Groongaデータベースに対する検索処理や更新処理のための条件を表現するためのデータ構造で、複数の条件を再帰的に組み合わせてより複雑な条件を表現することができます。grn_exprによって表現されたクエリを実行するためには、grn_table_select()関数を使用します。
-Groonga実行ファイル
-^^^^^^^^^^^^^^^^^^^
-Groongaデータベースを操作するためのコマンドインタープリタです。渡されたコマンドを解釈し、実行結果を返します。コマンドの実処理はC言語で記述されます。ユーザがC言語で定義した関数を新たなコマンドとしてGroonga実行ファイルに組み込むことができます。各コマンドはいくつかの文字列引数を受け取り、これをクエリとして解釈して実行します。引数をgrn_exprとして解釈するか、別の形式として解釈してDB_APIを使ってデータベースを操作するかはコマンド毎に自由に決めることができます。
-grn_exprで表現できるクエリ
---------------------------
-grn_exprは代入や関数呼び出しのような様々な操作を表現できますが、この中で検索クエリを表現するgrn_exprのことを特に条件式とよびます。条件式を構成する個々の要素を関係式と呼びます。条件式は一個以上の関係式か、あるいは条件式を論理演算子で結合したものです。
-論理演算子は、以下の3種類があります。
-::
- && (論理積)
- || (論理和)
- !  (否定)
-関係式は、下記の11種類が用意されています。また、ユーザが定義した関数を新たな関係式として使うこともできます。
-::
- equal(==)
- not_equal(!=)
- less(<)
- greater(>)
- less_equal(<=)
- greater_equal(>=)
- contain()
- near()
- similar()
- prefix()
- suffix()
-grn_table_select()
-------------------
-grn_table_select()関数は、grn_exprで表現された検索クエリを実行するときに使います。引数として、検索対象となるテーブル、クエリを表すgrn_expr、検索結果を格納するテーブル、それに検索にマッチしたレコードを検索結果にどのように反映するかを指定する演算子を渡します。演算子と指定できるのは下記の4種類です。
-::
- GRN_OP_OR
- GRN_OP_AND
- GRN_OP_BUT
- GRN_OP_ADJUST
-GRN_OP_ORは、検索対象テーブルの中からクエリにマッチするレコードを検索結果テーブルに加えます。GRN_OP_OR以外の演算子は、検索結果テーブルが空でない場合にだけ意味を持ちます。GRN_OP_ANDは、検索結果テーブルの中からクエリにマッチしないレコードを取り除きます。GRN_OP_BUTは、検索結果テーブルの中からクエリにマッチするレコードを取り除きます。GRN_OP_ADJUSTは、検索結果テーブルの中でクエリにマッチするレコードに対してスコア値の更新のみを行います。
-grn_table_select()は、データベース上に定義されたテーブルや索引などを組み合わせて可能な限り高速に指定されたクエリを実行しようとします。
-関係式
-------
-関係式は、検索しようとしているデータが満たすべき条件を、指定した値の間の関係として表現します。いずれの関係式も、その関係が成り立ったときに評価されるcallback、コールバック関数に渡されるargとを引数として指定することができます。callbackが与えられず、argのみが数値で与えられた場合はスコア値の係数とみなされます。主な関係式について説明します。
-equal(v1, v2, arg, callback)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-v1の値とv2の値が等しいことを表します。
-not_equal(v1, v2, arg, callback)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-v1の値とv2の値が等しくないことを表します。
-less(v1, v2, arg, callback)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-v1の値がv2の値よりも小さいことを表します。
-greater(v1, v2, arg, callback)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-v1の値がv2の値よりも大きいことを表します。
-less_equal(v1, v2, arg, callback)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-v1の値がv2の値と等しいか小さいことを表します。
-greater_equal(v1, v2, arg, callback)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-v1の値がv2の値と等しいか大きいことを表します。
-contain(v1, v2, mode, arg, callback)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-v1の値がv2の値を含んでいることを表します。また、v1の値が要素に分解されるとき、それぞれの要素に対して二つ目の要素が一致するためのmodeとして下記のいずれかを指定することができます。
-::
- EXACT: v2の値もv1の値と同様に要素に分解したとき、それぞれの要素が完全に一致する(デフォルト)
- UNSPLIT: v2の値は要素に分解しない
- PREFIX: v1の値の要素がv2の値に前方一致する
- SUFFIX: v1の値の要素がv2の値に後方一致する
- PARTIAL: v1の値の要素がv2の値に中間一致する
-near(v1, v2, arg, callback)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-v1の値の中に、v2の値の要素が接近して含まれていることを表します。(v2には値の配列を渡します)
-similar(v1, v2, arg, callback)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-v1の値とv2の値が類似していることを表します。
-prefix(v1, v2, arg, callback)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-v1の値がv2の値に対して前方一致することを表します。
-suffix(v1, v2, arg, callback)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-v1の値がv2の値に対して後方一致することを表します。
-クエリの実例
-============
-grn_exprを使って様々な検索クエリを表現することができます。
-検索例1
--------
-::
- GRN_EXPR_CREATE_FOR_QUERY(ctx, table, query, var);
- grn_expr_append_obj(ctx, query, contain, GRN_OP_PUSH, 1);
- grn_expr_append_obj(ctx, query, column, GRN_OP_PUSH, 1);
- grn_expr_append_const(ctx, query, string, GRN_OP_PUSH, 1);
- grn_expr_append_op(ctx, query, GRN_OP_CALL, 3);
- result = grn_table_select(ctx, table, query, NULL, GRN_OP_OR);
-tableのcolumnの値がstringを含むレコードをresultに返します。columnの値が'needle in haystack'であるレコードr1と、columnの値が'haystack'であるレコードr2がtableに登録されていたとき、stringに'needle'を指定したなら、レコードr1のみがヒットします。
-検索例2
--------
-::
- GRN_EXPR_CREATE_FOR_QUERY(ctx, table, query, var);
- grn_expr_append_obj(ctx, query, contain, GRN_OP_PUSH, 1);
- grn_expr_append_obj(ctx, query, column1, GRN_OP_PUSH, 1);
- grn_expr_append_const(ctx, query, string, GRN_OP_PUSH, 1);
- grn_expr_append_const(ctx, query, exact, GRN_OP_PUSH, 1);
- grn_expr_append_const(ctx, query, score1, GRN_OP_PUSH, 1);
- grn_expr_append_op(ctx, query, GRN_OP_CALL, 5);
- result = grn_table_select(ctx, table, query, NULL, GRN_OP_OR);
- grn_obj_close(ctx, query);
- GRN_EXPR_CREATE_FOR_QUERY(ctx, table, query, var);
- grn_expr_append_obj(ctx, query, contain, GRN_OP_PUSH, 1);
- grn_expr_append_obj(ctx, query, column2, GRN_OP_PUSH, 1);
- grn_expr_append_const(ctx, query, string, GRN_OP_PUSH, 1);
- grn_expr_append_const(ctx, query, exact, GRN_OP_PUSH, 1);
- grn_expr_append_const(ctx, query, score2, GRN_OP_PUSH, 1);
- grn_expr_append_op(ctx, query, GRN_OP_CALL, 5);
- grn_table_select(ctx, table, query, result, GRN_OP_ADJUST);
- grn_obj_close(ctx, query);
-tableのcolumn1の値がstringにexactモードでヒットするレコードについて得られるスコア値にscore1を積算してresultにセットします。次に、resultにセットされたレコードのうち、column2の値がstringにexactモードでヒットするレコードについては、得られたスコア値にscore2を積算したものを、元のスコア値に加えます。
-検索例3
--------
-::
- GRN_EXPR_CREATE_FOR_QUERY(ctx, table, query, var);
- grn_expr_append_obj(ctx, query, contain, GRN_OP_PUSH, 1);
- grn_expr_append_obj(ctx, query, column1, GRN_OP_PUSH, 1);
- grn_expr_append_const(ctx, query, string, GRN_OP_PUSH, 1);
- grn_expr_append_const(ctx, query, exact, GRN_OP_PUSH, 1);
- grn_expr_append_const(ctx, query, score1, GRN_OP_PUSH, 1);
- grn_expr_append_op(ctx, query, GRN_OP_CALL, 5);
- result = grn_table_select(ctx, table, query, NULL, GRN_OP_OR);
- grn_obj_close(ctx, query);
- if (grn_table_size(ctx, result) < t1) {
-   GRN_EXPR_CREATE_FOR_QUERY(ctx, table, query, var);
-   grn_expr_append_obj(ctx, query, contain, GRN_OP_PUSH, 1);
-   grn_expr_append_obj(ctx, query, column1, GRN_OP_PUSH, 1);
-   grn_expr_append_const(ctx, query, string, GRN_OP_PUSH, 1);
-   grn_expr_append_const(ctx, query, partial, GRN_OP_PUSH, 1);
-   grn_expr_append_const(ctx, query, score2, GRN_OP_PUSH, 1);
-   grn_expr_append_op(ctx, query, GRN_OP_CALL, 3);
-   grn_table_select(ctx, table, query, result, GRN_OP_OR);
-   grn_obj_close(ctx, query);
- }
-tableのcolumn1の値がstringにexactモードでヒットするレコードについて得られるスコア値にscore1を積算してresultにセットします。得られた検索結果数がt1よりも小さい場合は、partialモードで再度検索し、ヒットしたレコードについて得られるスコア値にscore2を積算してresultに追加します。
-検索例4
--------
-::
- GRN_EXPR_CREATE_FOR_QUERY(ctx, table, query, var);
- grn_expr_append_obj(ctx, query, contain, GRN_OP_PUSH, 1);
- grn_expr_append_const(ctx, query, string, GRN_OP_PUSH, 1);
- grn_expr_append_obj(ctx, query, column, GRN_OP_PUSH, 1);
- grn_expr_append_op(ctx, query, GRN_OP_CALL, 3);
- result = grn_table_select(ctx, table, query, NULL, GRN_OP_OR);
-tableのcolumnの値がstringに含まれるレコードをresultに返します。
-columnの値が'needle'であるレコードr1と、columnの値が'haystack'であるレコードr2がtableに登録されていたとき、stringに'hay in haystack'を指定したなら、レコードr2のみがヒットします。

data/vendor/local/share/doc/groonga/en/html/_sources/contribution/development/release.txt DELETED Viewed

@@ -1,790 +0,0 @@
-.. -*- rst -*-
-.. highlightlang:: none
-リリース手順
-============
-前提条件
-*********
-リリース手順の前提条件は以下の通りです。
-* ビルド環境は 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
-最初の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 python-sphinx bison
-Debian系（.deb）やRed Hat系（.rpm）パッケージのビルドには `Vagrant <https://www.vagrantup.com/>`_ を使用します。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
-パッケージ署名用秘密鍵のインポート
-----------------------------------
-リリース作業では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
-この作業は、新規にリリースを行うことになった担当者やパッケージに署名する鍵に変更があった場合などに行います。
-PPA用の鍵の登録
----------------
-この作業は、新規にリリースを行うことになった担当者のみ行います。
-[Launchpad](https://launchpad.net/)にアカウントを作成し、自分の普段使いの秘密鍵を登録した上で、他のリリース担当者に依頼して[Groongaチーム](https://launchpad.net/~groonga)に追加してもらって下さい。
-リリース作業用ディレクトリの作成
---------------------------------
-Groongaのリリース作業ではリリース専用の環境下(コンパイルフラグ)でビルドする必要があります。
-リリース時と開発時でディレクトリを分けずに作業することもできますが、誤ったコンパイルフラグでリリースしてしまう危険があります。
-そのため、以降の説明では$GROONGA_DIR以下のディレクトリにリリース用の作業ディレクトリ(groonga.clean)としてソースコードをcloneしたものとして説明します。
-毎回のリリースで行う手順
-************************
-Groongaのソースコード取得
--------------------------
-リリース用のクリーンな状態でソースコードを取得するために$GROONGA_DIRにて以下のコマンドを実行します。::
-    % git clone --recursive git@github.com:groonga/groonga.git groonga.clean---------------------------
-この作業はリリース作業ごとに行います。
-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のソースを取得できます。
-cutterのソースコード取得
-------------------------
-Groongaのリリース作業では、cutterに含まれるスクリプトを使用しています。
-そこであらかじめ用意しておいた$HOME/work/cutterディレクトリにてcutterのソースコードを以下のコマンドにて取得します。::
-    % git clone git@github.com:clear-code/cutter.git
-これで、$CUTTER_SOURCE_PATHディレクトリにcutterのソースを取得できます。
-変更点のまとめ
---------------
-前回リリース時からの変更点を$GROONGA_CLONE_DIR/doc/source/news.rst（英語）にまとめます。
-ここでまとめた内容についてはリリースアナウンスにも使用します。
-前回リリースからの変更履歴を参照するには以下のコマンドを実行します。::
-   % git log -p --reverse $(git tag | tail -1)..
-ログを^commitで検索しながら、以下の基準を目安として変更点を追記していきます。
-含めるもの
-* ユーザへ影響するような変更
-* 互換性がなくなるような変更
-含めないもの
-* 内部的な変更(変数名の変更やらリファクタリング)
-具体的な変更点の記述方法は後述します。
-configureスクリプトの生成
--------------------------
-Groongaのソースコードをcloneした時点ではconfigureスクリプトが含まれておらず、そのままmakeコマンドにてビルドすることができません。
-$GROONGA_CLONE_DIRにてautogen.shを以下のように実行します。::
-    % sh autogen.sh
-このコマンドの実行により、configureスクリプトが生成されます。
-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のリポジトリにパッケージをアップロードできる事を確認しておいてください。
-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-examplesの実行
---------------------------
-ドキュメントに埋め込まれている実行結果を更新するために、以下のコマンドを実行します。::
-    % cd doc && make update-examples
-doc/source/examples以下が更新されるので、それらをコミットします。
-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
-修正が必要な箇所を調べて、 ``***.edit`` というファイルを適宜修正します。
-    % cd groonga/doc/locale
-    % gir diff
-ファイルを編集したら、再度poファイルとHTMLを更新するために以下のコマンドを実行します。::
-    % make update-po
-    % make -C doc/locale/ja html
-    % make -C doc/locale/en html
-確認が完了したら、翻訳済みpoファイルをコミットします。
-リリースタグの設定
-------------------
-リリース用のタグを打つには以下のコマンドを実行します。::
-    % make tag
-.. note::
-   タグを打った後にconfigureを実行することで、ドキュメント生成時のバージョン番号に反映されます。
-リリース用アーカイブファイルの作成
-----------------------------------
-リリース用のソースアーカイブファイルを作成するために以下のコマンドを$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 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
-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
-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サーバ経由で参照できるようにします。
-yumの場合::
-    % ruby -run -e httpd -- packages/yum/repositories
-    % yum update
-    ...
-aptの場合::
-    % ruby -run -e httpd -- packages/apt/repositories
-    % sudo apt update
-    ...
-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
-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系の場合の動作確認手順は以下の通りとなります。
-* 旧バージョンをテスト環境へとインストールする
-* テスト環境の/etc/hostsを書き換えてpackages.groonga.orgがホストを
-  参照するように変更する
-* ホストでwebサーバを起動してドキュメントルートをビルド環境のもの
-  (repositories/apt/packages)に設定する
-* アップグレード手順を実行する
-* grntestのアーカイブを展開してインストールしたバージョンでテストを実
-  行する
-* grntestの正常終了を確認する
-Red Hat系の場合
-~~~~~~~~~~~~~~~
-Red Hat系の場合の動作確認手順は以下の通りとなります。
-* 旧バージョンをテスト環境へとインストール
-* テスト環境の/etc/hostsを書き換えてpackages.groonga.orgがホストを参照するように変更する
-* ホストでwebサーバを起動してドキュメントルートをビルド環境のもの(packages/yum/repositories)に設定する
-* アップグレード手順を実行する
-* grntestのアーカイブを展開してインストールしたバージョンでテストを実行する
-* grntestの正常終了を確認する
-Windows向けの場合
-~~~~~~~~~~~~~~~~~
-* テスト環境で新規インストール/上書きインストールを行う
-* grntestのアーカイブを展開してインストールしたバージョンでテストを実行する
-* grntestの正常終了を確認する
-zipアーカイブも同様にしてgrntestを実行し動作確認を行います。
-リリースアナウンスの作成
-------------------------
-リリースの際にはリリースアナウンスを流して、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等でのリリースアナウンスの際はここで用意したアナウンス文の要約を使用します。
-パッケージのアップロード
-------------------------
-動作確認が完了し、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へと反映されます。
-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で確認できます。
-  https://launchpad.net/~groonga/+archive/ubuntu/ppa
-Ubuntu用パッケージの公開の取り消し
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-LaunchpadのGroongaチームのページで対象のPPAを選択し、バージョン一覧の上にある「View package details」リンクの先で「Delete packages」リンクを辿ると、アップロード済みパッケージを削除できる。
-例；[不安定版リポジトリのパッケージの削除用のページ](https://launchpad.net/~groonga/+archive/ubuntu/nightly/+delete-packages)。
-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
-    ---
-ドキュメントのアップロード
---------------------------
-doc/source以下のドキュメントを更新、翻訳まで完了している状態で、ドキュメントのアップロード作業を行います。
-そのためにはまず以下のコマンドを実行します。::
-    % make update-document
-これによりcloneしておいたgroonga.orgのdoc/locale以下に更新したドキュメントがコピーされます。
-生成されているドキュメントに問題のないことを確認できたら、コミット、pushしてgroonga.orgへと反映します。
-Homebrewの更新
---------------
-この手順は省略可能です（Homebrewの更新はGroongaプロジェクト本体のリリース要件には含まれません）。
-OS Xでのパッケージ管理方法として `Homebrew <http://brew.sh/>`_ があります。
-Groongaを簡単にインストールできるようにするために、Homebrewへpull requestを送ります。
-  https://github.com/Homebrew/homebrew-core
-すでにGroongaのFormulaは取り込まれているので、リリースのたびにFormulaの内容を更新する作業を実施します。
-Groonga 3.0.6のときは以下のように更新してpull requestを送りました。
-  https://github.com/mxcl/homebrew/pull/21456/files
-上記URLを参照するとわかるようにソースアーカイブのurlとsha1チェックサムを更新します。
-リリースアナウンス
-------------------
-作成したリリースアナウンスをメーリングリストへと流します。
-* groonga-dev groonga-dev@lists.osdn.me
-* Groonga-talk groonga-talk@lists.sourceforge.net
-Twitterでリリースアナウンスをする
----------------------------------
-blogroongaのリリースエントリには「リンクをあなたのフォロワーに共有する」ためのツイートボタンがあるので、そのボタンを使ってリリースアナウンスします。(画面下部に配置されている)
-このボタンを経由する場合、ツイート内容に自動的にリリースタイトル(「groonga 2.0.8リリース」など)とblogroongaのリリースエントリのURLが挿入されます。
-この作業はblogroongaの英語版、日本語版それぞれで行います。
-あらかじめgroongaアカウントでログインしておくとアナウンスを円滑に行うことができます。
-Facebookでリリースアナウンスをする
-----------------------------------
-FacebookにGroongaグループがあります。
-https://www.facebook.com/groonga/
-Groongaグループのメンバーになると、個人のアカウントではなく、Groongaグループのメンバーとして投稿できます。
-ブログエントリなどをもとに、リリースアナウンスを投稿します。
-以上でリリース作業は終了です。
-リリース後にやること
---------------------
-リリースアナウンスを流し終えたら、次期バージョンの開発が始まります。
-* Groonga のbase_versionの更新
-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 PARALLEL=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