モジュールのリリースとバージョン管理ワークフロー

他の開発者が使用するためのモジュールを開発する際には、モジュールを使用する開発者にとって信頼性が高く一貫したエクスペリエンスを確保するのに役立つワークフローに従うことができます。このトピックでは、そのワークフローの概要手順について説明します。

モジュール開発の概要については、「モジュールの開発と公開」を参照してください。

こちらも参照

一般的なワークフローステップ

次のシーケンスは、新しい例モジュールのリリースとバージョン管理ワークフローステップを示しています。各ステップの詳細については、このトピックのセクションを参照してください。

  1. モジュールを開始する と、開発者が使いやすく、保守しやすくするためにソースを整理します。

    モジュールの開発が初めての場合は、「チュートリアル：Goモジュールの作成」を参照してください。

    Goの分散型モジュール公開システムでは、コードの編成方法が重要です。詳細については、「モジュールソースの管理」を参照してください。

  2. 公開されていないモジュール内の関数を呼び出すローカルクライアントコードの記述の準備をします。

    モジュールを公開する前は、`go get`などのコマンドを使用した一般的な依存関係管理ワークフローでは使用できません。この段階でモジュールコードをテストする良い方法は、呼び出しコードのローカルディレクトリにある間に試してみることです。

    ローカル開発の詳細については、「公開されていないモジュールに対するコーディング」を参照してください。

  3. モジュールのコードが他の開発者が試せる準備ができたら、アルファ版やベータ版などのv0プレリリースの公開を開始します。「プレリリースバージョンの公開」を参照してください。

  4. v0をリリースする これは安定性が保証されていませんが、ユーザーが試すことができます。「最初の（不安定な）バージョンの公開」を参照してください。

  5. v0バージョンが公開された後、その新しいバージョンをリリースし続けることができます（そしてする必要があります！）。

    これらの新しいバージョンには、バグ修正（パッチリリース）、モジュールの公開APIへの追加（マイナーリリース）、および破壊的変更が含まれる場合があります。v0リリースでは安定性や下位互換性が保証されないため、そのバージョンで破壊的変更を加えることができます。

    詳細については、「バグ修正の公開」と「非破壊的API変更の公開」を参照してください。

  6. 安定したバージョンをリリースする準備ができたら、アルファ版とベータ版としてプレリリースを公開します。「プレリリースバージョンの公開」を参照してください。

  7. 最初の安定版としてv1をリリースします。

    これは、モジュールの安定性に関するコミットメントを行う最初のリリースです。「最初の安定バージョンの公開」を参照してください。

  8. v1バージョンでは、バグの修正を続け、必要に応じてモジュールの公開APIに追加します。

    詳細については、「バグ修正の公開」と「非破壊的API変更の公開」を参照してください。

  9. 避けられない場合は、新しいメジャーバージョンで破壊的変更を公開します。

    v1.x.xからv2.x.xなどへのメジャーバージョンアップデートは、モジュールのユーザーにとって非常に破壊的なアップグレードになる可能性があります。これは最後の手段とすべきです。「破壊的API変更の公開」を参照してください。

公開されていないモジュールに対するコーディング

モジュールまたはモジュールの新しいバージョンを開発し始めると、まだ公開されていません。モジュールを公開する前は、Goコマンドを使用してモジュールを依存関係として追加することはできません。代わりに、最初は、公開されていないモジュール内の関数を呼び出す別のモジュールでクライアントコードを記述する際に、ローカルファイルシステム上のモジュールのコピーを参照する必要があります。

クライアントモジュールの`go.mod`ファイルで`replace`ディレクティブを使用することにより、クライアントモジュールからローカルでモジュールを参照できます。詳細については、「ローカルディレクトリのモジュールコードの要求」を参照してください。

プレリリースバージョンの公開

プレリリースバージョンを公開して、モジュールを試用し、フィードバックを提供できるようにすることができます。プレリリースバージョンには、安定性の保証はありません。

プレリリースバージョンの番号には、プレリリース識別子が追加されます。バージョン番号の詳細については、「モジュールのバージョン番号付け」を参照してください。

2つの例を次に示します。

v0.2.1-beta.1
v1.2.3-alpha

プレリリースを使用できるようにする際には、プレリリースを使用する開発者は、`go get`コマンドを使用してバージョンを明示的に指定する必要があることに注意してください。これは、デフォルトで`go`コマンドが、要求しているモジュールを探す際に、プレリリースバージョンよりもリリースバージョンを優先するためです。そのため、開発者は、次の例のように、明示的に指定してプレリリースを取得する必要があります。

go get example.com/theirmodule@v1.2.3-alpha

プレリリースを公開するには、リポジトリ内のモジュールコードにタグ付けし、タグにプレリリース識別子を指定します。詳細については、「モジュールの公開」を参照してください。

最初の（不安定な）バージョンの公開

プレリリースバージョンを公開する場合と同様に、安定性や下位互換性が保証されていないリリースバージョンを公開して、ユーザーがモジュールを試用し、フィードバックを提供できるようにすることができます。

不安定なリリースは、バージョン番号がv0.x.x範囲にあるものです。v0バージョンでは、安定性や下位互換性が保証されません。しかし、v1以降で安定性に関するコミットメントを行う前に、フィードバックを取得し、APIを改良するための方法を提供します。詳細については、「モジュールのバージョン番号付け」を参照してください。

他の公開済みバージョンと同様に、安定したv1バージョンをリリースする際に変更を加えるにつれて、v0バージョンのマイナー部分とパッチ部分をインクリメントできます。たとえば、v0.0.0をリリースした後、最初のバグ修正セットを使用してv0.0.1をリリースできます。

バージョン番号の例を次に示します。

v0.1.3

不安定なリリースを公開するには、リポジトリ内のモジュールコードにタグ付けし、タグにv0バージョン番号を指定します。詳細については、「モジュールの公開」を参照してください。

最初の安定バージョンの公開

最初の安定リリースのバージョン番号はv1.x.xになります。最初の安定リリースは、フィードバックを取得し、バグを修正し、ユーザーのためにモジュールを安定化するためのプレリリースとv0リリースに続きます。

v1リリースでは、モジュールを使用する開発者に対して次のコミットメントを行います。

注：最初のメジャーバージョンはv0リリースになる可能性がありますが、v0バージョンは安定性または下位互換性の保証を示すものではありません。その結果、v0からv1にインクリメントする際には、v0リリースは安定したリリースと見なされなかったため、下位互換性を壊すことを気にする必要はありません。

バージョン番号の詳細については、「モジュールのバージョン番号付け」を参照してください。

安定したバージョン番号の例を次に示します。

v1.0.0

最初の安定リリースを公開するには、リポジトリ内のモジュールコードにタグ付けし、タグにv1バージョン番号を指定します。詳細については、「モジュールの公開」を参照してください。

バグ修正の公開

変更がバグ修正のみに限定されているリリースを公開できます。これは、パッチリリースと呼ばれます。

パッチリリースには、マイナーな変更のみが含まれます。具体的には、モジュールの公開APIへの変更は含まれません。消費コードの開発者は、このバージョンに安全にアップグレードでき、コードを変更する必要はありません。

注：パッチリリースでは、そのモジュールの独自の推移的な依存関係をパッチリリース以上にアップグレードしないようにしてください。そうしないと、モジュールのパッチにアップグレードしたユーザーが、使用している推移的な依存関係に侵襲的な変更を誤って取り込む可能性があります。

パッチリリースは、モジュールのバージョン番号のパッチ部分をインクリメントします。詳細については、「モジュールのバージョン番号付け」を参照してください。

次の例では、v1.0.1はパッチリリースです。

旧バージョン：v1.0.0

新バージョン：v1.0.1

パッチリリースを公開するには、リポジトリ内のモジュールコードにタグ付けし、タグのパッチバージョン番号をインクリメントします。詳細については、「モジュールの公開」を参照してください。

非破壊的API変更の公開

モジュールの公開APIに非破壊的な変更を加え、それらの変更をマイナーバージョンリリースで公開できます。

このバージョンはAPIを変更しますが、呼び出しコードを壊すような方法ではありません。これには、モジュールの独自の依存関係の変更、または新しい関数、メソッド、構造体のフィールド、または型の追加が含まれる場合があります。この種のリリースには変更が含まれていますが、モジュールの関数を呼び出す既存のコードとの下位互換性と安定性を保証します。

マイナーリリースは、モジュールのバージョン番号のマイナー部分をインクリメントします。詳細については、「モジュールのバージョン番号付け」を参照してください。

次の例では、v1.1.0はマイナーリリースです。

旧バージョン：v1.0.1

新バージョン：v1.1.0

マイナーリリースを公開するには、リポジトリ内のモジュールコードにタグを付け、タグ内のマイナーバージョン番号を増分します。詳細はモジュールの公開を参照してください。

破壊的API変更の公開

メジャーバージョンリリースを公開することで、後方互換性を損なうバージョンを公開できます。

メジャーバージョンリリースは、後方互換性を保証するものではありません。通常、モジュールの公開APIに対する変更が含まれており、モジュールの以前のバージョンを使用しているコードを破壊するためです。

メジャーバージョンのアップグレードが、モジュールに依存するコードに及ぼす破壊的な影響を考えると、可能な限りメジャーバージョンの更新は避けるべきです。メジャーバージョンの更新の詳細については、メジャーバージョン更新の開発を参照してください。破壊的な変更を回避するための戦略については、ブログ記事モジュールの互換性を維持するを参照してください。

他の種類のバージョンの公開は基本的にバージョン番号でモジュールコードにタグを付けることを必要とするのに対し、メジャーバージョン更新の公開には、より多くの手順が必要です。

  1. 新しいメジャーバージョンの開発を開始する前に、リポジトリ内に新しいバージョンのソースのための場所を作成します。

    これを行う1つの方法は、新しいメジャーバージョンとその後のマイナーバージョンおよびパッチバージョン専用の新しいブランチをリポジトリ内に作成することです。詳細はモジュールソースの管理を参照してください。

  2. モジュールのgo.modファイルで、次の例のようにモジュールパスに新しいメジャーバージョン番号を追加して修正します。

    example.com/mymodule/v2

    モジュールパスはモジュールの識別子であるため、この変更により、事実上新しいモジュールが作成されます。また、パッケージパスも変更され、開発者が意図せずコードを破壊するバージョンをインポートすることがなくなります。代わりに、アップグレードしたい開発者は、古いパスを新しいパスに明示的に置き換えます。

  3. コード内で、更新しているモジュールのパッケージをインポートしているすべてのパッケージパスを変更します。これは、モジュールパスを変更したためです。

  4. 新しいリリースと同様に、正式リリースの前にフィードバックとバグレポートを得るために、プレリリースバージョンを公開する必要があります。

  5. リポジトリ内のモジュールコードにタグを付け、タグ内のメジャーバージョン番号を増分（例：v1.5.2からv2.0.0）することで、新しいメジャーバージョンを公開します。

    詳細はモジュールの公開を参照してください。

go.devは、GoogleのCookieを使用して、サービスの品質の提供と向上、およびトラフィックの分析を行っています。詳細はこちら。