モジュールバージョン番号
モジュールの開発者は、モジュールバージョン番号の各部分を使用して、バージョンの安定性と後方互換性を示します。新しいリリースごとに、モジュールのリリースバージョン番号は、前のリリース以降のモジュールの変更の内容を具体的に反映します。
外部モジュールを使用するコードを開発する場合、アップグレードを検討する際にバージョン番号を使用して、外部モジュールの安定性を理解できます。独自のモジュールを開発する場合、バージョン番号は、モジュールの安定性と後方互換性を他の開発者に示します。
このトピックでは、モジュールバージョン番号の意味について説明します。
関連項目
- コードで外部パッケージを使用している場合は、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 リファレンスを参照してください。