メジャーバージョンアップデートの開発

新しいバージョンで加える変更がモジュールのユーザーに対して後方互換性を保証できない場合、メジャーバージョンにアップデートする必要があります。例えば、モジュールの以前のバージョンを使用しているクライアントコードを壊すようにモジュールのパブリックAPIを変更する場合、この変更を行います。

注：メジャー、マイナー、パッチ、プレリリースといった各リリースタイプは、モジュールのユーザーにとって異なる意味を持ちます。これらのユーザーは、リリースが自身のコードに与えるリスクのレベルを理解するために、これらの違いに依拠しています。言い換えれば、リリースを準備する際には、そのバージョン番号が前のリリースからの変更の性質を正確に反映していることを確認してください。バージョン番号の詳細については、「モジュールのバージョン番号」を参照してください。

こちらも参照

メジャーバージョンアップデートの考慮事項

新しいメジャーバージョンへのアップデートは、絶対に必要である場合にのみ行うべきです。メジャーバージョンアップデートは、あなたとモジュールのユーザーの両方にとって大きな変更を意味します。メジャーバージョンアップデートを検討する際には、次の点を考慮してください。

  • 新しいメジャーバージョンをリリースすることが、以前のメジャーバージョンのサポートにとって何を意味するのかをユーザーに明確に伝えてください。

    以前のバージョンは非推奨になりますか？以前と同じようにサポートされますか？バグ修正を含め、以前のバージョンを維持しますか？

  • 古いバージョンと新しいバージョンの2つのバージョンのメンテナンスを引き受ける準備をしてください。例えば、一方のバグを修正した場合、その修正をもう一方にも移植することがよくあります。

  • 新しいメジャーバージョンは、依存関係管理の観点からは新しいモジュールであることに注意してください。ユーザーは、単にアップグレードするのではなく、リリース後に新しいモジュールを使用するためにアップデートする必要があります。

    それは、新しいメジャーバージョンが前のメジャーバージョンとは異なるモジュールパスを持つためです。例えば、モジュールパスがexample.com/mymoduleのモジュールの場合、v2バージョンはexample.com/mymodule/v2というモジュールパスを持ちます。

  • 新しいメジャーバージョンを開発する際には、新しいモジュールからパッケージをインポートするすべての場所でインポートパスも更新する必要があります。モジュールのユーザーも、新しいメジャーバージョンにアップグレードしたい場合は、インポートパスを更新する必要があります。

メジャーリリースに向けたブランチング

新しいメジャーバージョンの開発を準備する際にソースを扱う最も簡単なアプローチは、前のメジャーバージョンの最新バージョンでリポジトリをブランチすることです。

例えば、コマンドプロンプトでモジュールのルートディレクトリに移動し、そこで新しいv2ブランチを作成できます。

$ cd mymodule
$ git checkout -b v2
Switched to a new branch "v2"

Diagram illustrating a repository branched from master to v2

ソースをブランチした後、新しいバージョンのソースに次の変更を加える必要があります。

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

    • 既存のバージョン: example.com/mymodule
    • 新しいバージョン: example.com/mymodule/v2

  • Goコードでは、モジュールからパッケージをインポートするすべてのインポートパッケージパスを更新し、モジュールパス部分にメジャーバージョン番号を追加します。

    • 古いインポート文: import "example.com/mymodule/package1"
    • 新しいインポート文: import "example.com/mymodule/v2/package1"

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

go.dev は、サービスの品質を提供および向上させ、トラフィックを分析するために、Google の Cookie を使用しています。詳細はこちらをご覧ください。