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

潜在的な新バージョンで行っている変更が、モジュールのユーザーに対する後方互換性を保証できない場合は、メジャーバージョンにアップデートする必要があります。たとえば、モジュールの公開APIを変更して、モジュールの以前のバージョンを使用しているクライアントコードが壊れる場合に、この変更を行います。

注記：メジャー、マイナー、パッチ、プレリリースの各リリースの種類は、モジュールのユーザーにとって異なる意味を持ちます。これらのユーザーは、これらの違いに依存して、リリースが独自のコードに及ぼすリスクのレベルを理解しています。つまり、リリースを準備する際には、そのバージョン番号が、前のリリース以降の変更の内容を正確に反映していることを確認してください。バージョン番号の詳細については、「モジュールのバージョン番号付け」を参照してください。

参照

• モジュール開発の概要については、「モジュールの開発と公開」を参照してください。
• エンドツーエンドのビューについては、「モジュールのリリースとバージョン管理ワークフロー」を参照してください。

メジャーバージョンアップデートに関する考慮事項

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

• 新しいメジャーバージョンのリリースが、以前のメジャーバージョンのサポートにどのような意味を持つのかを、ユーザーに明確に説明してください。

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

• 古いバージョンと新しいバージョンの2つのバージョンのメンテナンスを行う準備をしましょう。たとえば、一方のバグを修正する場合は、多くの場合、それらの修正を他方に移植する必要があります。

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

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

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

メジャーリリースのブランチング

新しいメジャーバージョンを開発する準備をする際のソースの処理で最も簡単な方法は、前のメジャーバージョンの最新バージョンでリポジトリをブランチすることです。

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

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

ソースをブランチしたら、新しいバージョンのソースに対して次の変更を行う必要があります。

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

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

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

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

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