モジュールのバージョン管理

モジュールの開発者は、モジュールのバージョン番号の各部分を使用して、バージョンの安定性と後方互換性を示します。新しいリリースごとに、モジュールのリリースバージョン番号は、前のリリース以降のモジュールの変更の性質を具体的に反映します。

外部モジュールを使用するコードを開発する場合、バージョン番号を使用して、アップグレードを検討する際に外部モジュールの安定性を理解できます。独自のモジュールを開発する場合、バージョン番号は他の開発者にモジュールの安定性と後方互換性を示します。

このトピックでは、モジュールのバージョン番号が何を意味するかを説明します。

こちらも参照

• コードで外部パッケージを使用している場合、Goツールでそれらの依存関係を管理できます。詳細については、「依存関係の管理」を参照してください。
• 他の開発者が使用するモジュールを開発している場合は、モジュールを公開するときにバージョン番号を適用し、リポジトリにモジュールをタグ付けします。詳細については、「モジュールの公開」を参照してください。

リリースされたモジュールは、以下の図のようにセマンティックバージョニングモデルでバージョン番号を付けて公開されます。

以下の表は、バージョン番号の各部分がモジュールの安定性と後方互換性をどのように示すかを示しています。

バージョン段階	例	開発者へのメッセージ
開発中	自動擬似バージョン番号 v0.x.x	モジュールがまだ開発中で不安定であることを示します。このリリースには、後方互換性または安定性の保証はありません。
メジャーバージョン	v1.x.x	後方互換性のない公開APIの変更を示します。このリリースは、以前のメジャーバージョンとの後方互換性を保証しません。
マイナーバージョン	vx.4.x	後方互換性のある公開APIの変更を示します。このリリースは、後方互換性と安定性を保証します。
パッチバージョン	vx.x.1	モジュールの公開APIまたはその依存関係に影響しない変更を示します。このリリースは、後方互換性と安定性を保証します。
プレリリースバージョン	vx.x.x-beta.2	これはアルファ版やベータ版のようなプレリリースのマイルストーンであることを示します。このリリースには安定性の保証はありません。

開発中

モジュールがまだ開発中で不安定であることを示します。このリリースには、後方互換性または安定性の保証はありません。

バージョン番号は以下のいずれかの形式をとります。

擬似バージョン番号

v0.0.0-20170915032832-14c0d48ead0c

v0番号

v0.x.x

擬似バージョン番号

モジュールがリポジトリでタグ付けされていない場合、Goツールは、モジュール内の関数を呼び出すコードのgo.modファイルで使用するための擬似バージョン番号を生成します。

注：ベストプラクティスとして、独自の擬似バージョン番号を作成するのではなく、常にGoツールに生成させるようにしてください。

擬似バージョンは、モジュールの関数を使用するコードの開発者が、まだセマンティックバージョンタグでタグ付けされていないコミットに対して開発する必要がある場合に役立ちます。

擬似バージョン番号は、以下の形式で示すように、ダッシュで区切られた3つの部分で構成されます。

構文

baseVersionPrefix-timestamp-revisionIdentifier

パーツ

• baseVersionPrefix (vX.0.0 または vX.Y.Z-0) は、リビジョンの前のセマンティックバージョンタグから派生した値、またはそのようなタグがない場合は vX.0.0 から派生した値です。

• timestamp (yymmddhhmmss) は、リビジョンが作成されたUTC時刻です。Gitでは、これは作者時刻ではなくコミット時刻です。

• revisionIdentifier (abcdefabcdef) は、コミットハッシュの12文字のプレフィックス、またはSubversionではゼロ埋めされたリビジョン番号です。

v0番号

v0番号で公開されたモジュールには、メジャー、マイナー、パッチの各部分と、オプションのプレリリース識別子を持つ正式なセマンティックバージョン番号があります。

v0バージョンは本番環境で使用できますが、安定性や後方互換性の保証はありません。さらに、v1以降のバージョンでは、v0バージョンを使用するコードとの後方互換性が破られる可能性があります。このため、v0モジュール内の関数を使用するコードを持つ開発者は、v1がリリースされるまで互換性のない変更に適応する責任があります。

プレリリースバージョン

これは、アルファ版やベータ版のようなプレリリースのマイルストーンであることを示します。このリリースには安定性の保証はありません。

例

vx.x.x-beta.2

モジュールの開発者は、ハイフンとプレリリース識別子を追加することで、任意のmajor.minor.patchの組み合わせでプレリリース識別子を使用できます。

マイナーバージョン

モジュールの公開APIに対する後方互換性のある変更を示します。このリリースは、後方互換性と安定性を保証します。

例

vx.4.x

このバージョンはモジュールの公開APIを変更しますが、呼び出しコードを壊す方法ではありません。これには、モジュール自身の依存関係の変更や、新しい関数、メソッド、構造体フィールド、または型の追加が含まれる場合があります。

つまり、このバージョンには、他の開発者が使用したい新しい関数による拡張が含まれる可能性があります。ただし、以前のマイナーバージョンを使用している開発者は、それ以外にコードを変更する必要はありません。

パッチバージョン

モジュールの公開APIまたはその依存関係に影響しない変更を示します。このリリースは、後方互換性と安定性を保証します。

例

vx.x.1

この数値を増やす更新は、バグ修正などの軽微な変更のみです。使用するコードの開発者は、コードを変更することなく、このバージョンに安全にアップグレードできます。

メジャーバージョン

モジュールの公開APIにおける後方互換性のない変更を示します。このリリースは、以前のメジャーバージョンとの後方互換性を保証しません。

例

v1.x.x

v1以上のバージョン番号は、モジュールが使用可能であることを示します（プレリリースバージョンを除く）。

バージョン0は安定性や後方互換性の保証がないため、モジュールをv0からv1にアップグレードする開発者は、後方互換性を破る変更に適応する責任があることに注意してください。

モジュールの開発者は、この数値をv1より高くするのは必要な場合にのみ行うべきです。なぜなら、このバージョンアップグレードは、アップグレードされたモジュール内の関数を使用する開発者にとって重大な混乱を意味するからです。この混乱には、公開APIの後方互換性のない変更だけでなく、モジュールを使用する開発者がモジュールからパッケージをインポートする場所のパッケージパスを更新する必要があることも含まれます。

v1より高い数値へのメジャーバージョンアップデートでは、新しいモジュールパスも持ちます。これは、以下の例のように、モジュールパスにメジャーバージョン番号が追加されるためです。

module example.com/mymodule/v2 v2.0.0

メジャーバージョンアップデートにより、これはモジュールの以前のバージョンとは別の履歴を持つ新しいモジュールになります。他の開発者向けにモジュールを公開している場合は、「モジュールのリリースとバージョン管理のワークフロー」の「互換性のないAPI変更の公開」を参照してください。

moduleディレクティブの詳細については、「go.modリファレンス」を参照してください。