Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

[インデックス 12796] ファイルの概要

このコミットは、Go言語のコマンドラインツールであるgoコマンドのドキュメント、特にgo getコマンドに関するタグの扱いについての記述を更新するものです。具体的には、Go 1.0のリリースを控えて、パッケージ取得時のバージョン選択ロジックにおける「go1」タグの優位性を明確にし、それ以前のリリースサイクル（weeklyやrelease.rNN）に関する記述を削除しています。

コミット

commit efb134f8bf8fb22de6e5f0e8ad4e62d8a3671680
Author: Rob Pike <r@golang.org>
Date:   Fri Mar 30 13:07:10 2012 +1100

    cmd/go: update docs about tags for get command
    "go1" dominates. Delete the text about weekly and release.
    We can revisit this once the situation changes.
    
    R=golang-dev, rsc
    CC=golang-dev
    https://golang.org/cl/5969043

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/efb134f8bf8fb22de6e5f0e8ad4e62d8a3671680

元コミット内容

cmd/go: update docs about tags for get command
"go1" dominates. Delete the text about weekly and release.
We can revisit this once the situation changes.

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5969043

変更の背景

このコミットは、Go言語がバージョン1.0の安定版リリースを目前に控えていた時期に行われました。Go 1.0以前は、Goのリリースサイクルは現在とは異なり、weeklyビルドやrelease.rNNといった形式でバージョンが管理されていました。go getコマンドは、パッケージを取得する際に、ローカルのGoバージョンに一致するブランチやタグを探すロジックを持っていました。

しかし、Go 1.0のリリースは、Go言語の安定性と互換性を保証する重要なマイルストーンでした。Go 1.0以降は、APIの互換性が維持されることが強く約束され、これまでの開発版のような頻繁な変更はなくなります。この大きな変化に伴い、go getがパッケージのバージョンを選択する際の優先順位も変更する必要がありました。特に、Go 1.0環境で動作するパッケージは、go1というタグやブランチを持つことで、その互換性を示すことが推奨されるようになりました。

このコミットの目的は、go getのドキュメントを更新し、Go 1.0以降の新しいバージョン選択の振る舞いを正確に反映させることでした。具体的には、go1タグが最も優先されるべきバージョンであることを明確にし、もはや主流ではなくなるweeklyやrelease.rNNといった古いバージョン指定の概念をドキュメントから削除することで、ユーザーの混乱を防ぎ、Go 1.0への移行をスムーズにすることを意図しています。

前提知識の解説

1. go getコマンド

go getは、Go言語のパッケージ管理ツールであり、指定されたパッケージとその依存関係をリモートリポジトリからダウンロードし、ローカルのGOPATH（Go 1.11以降はGo Modulesのキャッシュ）にインストールするコマンドです。開発者が外部ライブラリをプロジェクトに組み込む際に不可欠なツールです。

go getの基本的な動作は以下の通りです。

  • 指定されたインポートパス（例: github.com/user/repo）に対応するリポジトリを特定します。
  • リポジトリをクローンまたはフェッチします。
  • 適切なバージョンのパッケージを選択し、コンパイルしてインストールします。

2. Go言語のバージョン管理（Go 1.0以前と以後）

  • Go 1.0以前: Go言語は活発に開発されており、APIの変更が頻繁に行われていました。この時期のGoのバージョンは、release.rNN（例: release.r60）やweekly.YYYY-MM-DD（例: weekly.2012-03-30）といった形式で識別されていました。go getは、ローカルのGoバージョンがこれらの形式に一致する場合、対応するタグやブランチを持つパッケージを探し、互換性のあるバージョンを取得しようと試みました。これは、開発版Goの特定のバージョンで動作するパッケージを確実に入手するための仕組みでした。
  • Go 1.0以降: 2012年3月28日にリリースされたGo 1.0は、Go言語の安定版としての最初のリリースであり、Go 1互換性保証が導入されました。これは、Go 1.xの範囲内では、既存のGo 1プログラムが将来のGo 1.xリリースでも動作し続けることを保証するものです。この保証により、Goエコシステムは安定し、開発者は安心してライブラリやアプリケーションを構築できるようになりました。 Go 1.0のリリースに伴い、パッケージのバージョン選択ロジックも簡素化され、安定版Go 1で動作するパッケージはgo1というタグを持つことが推奨されるようになりました。これにより、go getは、ローカルのGoがGo 1.xである場合、まずgo1タグを持つパッケージを探すようになります。

3. タグとブランチ

Gitなどのバージョン管理システムにおいて、

  • タグ: 特定のコミットに永続的な名前（例: v1.0.0, go1）を付けるものです。主にリリースバージョンや重要なマイルストーンを示すために使用されます。タグは通常、変更されません。
  • ブランチ: 開発の並行ラインです。新しい機能の開発やバグ修正のために作成され、最終的にはメインブランチにマージされます。

go getは、これらのタグやブランチを利用して、特定のGoバージョンと互換性のあるパッケージのソースコードを取得します。

技術的詳細

このコミットの技術的詳細は、go getコマンドがパッケージのバージョンを選択する際の内部ロジックと、そのロジックがユーザーにどのように伝えられるかというドキュメントの側面の両方に影響を与えます。

Go 1.0以前のgo getは、ローカルのGoインストールがrelease.rNNやweekly.YYYY-MM-DDのような開発版のバージョンである場合、リモートリポジトリ内でそれに対応するタグやブランチ（例: go.rNN、go.YYYY-MM-DD）を探し、そのバージョンを取得しようと試みました。これは、Go言語自体がまだ活発に開発中で、APIが頻繁に変更されていた時期には理にかなった挙動でした。特定の開発版Goで動作するパッケージを確実に入手するためには、そのGoバージョンに合わせたパッケージのバージョンを取得する必要があったからです。

しかし、Go 1.0のリリースにより、この状況は根本的に変わりました。Go 1.0は安定版であり、Go 1互換性保証が導入されたため、Go 1.xの範囲内ではAPIの互換性が維持されることになりました。これにより、パッケージ開発者は、Go 1.0以降のどのGoバージョンでも動作するパッケージに対して、単一のgo1タグを付けることで、その互換性を示すことができるようになりました。

このコミットは、この新しい現実を反映するために、go getのドキュメントと、おそらくは内部的なバージョン選択ロジック（ドキュメントの変更がコードの変更と同期しているため）を更新しています。

変更のポイント:

  1. go1タグの優位性: ドキュメントは、「ローカルのインストールがバージョンgo1を実行している場合、go getはgo1という名前のブランチまたはタグを探す」という新しい最も重要なルールを明確にしています。これは、Go 1.0以降の環境では、go1タグを持つパッケージが優先的に選択されることを意味します。
  2. 古いバージョン指定の削除: release.rNNやweekly.YYYY-MM-DDといった古い形式のバージョン指定に関する記述がドキュメントから削除されました。これは、これらの形式がGo 1.0以降のGoエコシステムではもはや主要な役割を果たさないことを示しています。
  3. フォールバックロジックの簡素化: 以前は、特定のバージョンが見つからない場合に「最も近いバージョン」や「最新バージョン」を取得するという複雑なフォールバックロジックが記述されていましたが、変更後は「そのようなバージョンが存在しない場合、パッケージの最新バージョンを取得する」というシンプルな記述になっています。これは、go1タグが優先され、それが見つからない場合は最新版で十分であるというGo 1.0以降の考え方を反映しています。

この変更は、GoエコシステムがGo 1.0の安定性に基づいて進化していく上で、go getがどのようにパッケージのバージョンを解決するかについてのユーザーの理解を簡素化し、明確にする上で非常に重要でした。

コアとなるコードの変更箇所

このコミットでは、以下の2つのファイルが変更されています。

  1. src/cmd/go/doc.go
  2. src/cmd/go/get.go

両ファイルで同様の変更が行われており、go getコマンドのヘルプドキュメントと、おそらくは内部的なgetコマンドのドキュメント文字列が更新されています。

src/cmd/go/doc.go の変更

--- a/src/cmd/go/doc.go
+++ b/src/cmd/go/doc.go
@@ -227,15 +227,11 @@ The -u flag instructs get to use the network to update the named packages
 and their dependencies.  By default, get uses the network to check out
 missing packages but does not use it to look for updates to existing packages.
 
-When checking out or updating a package, get looks for a branch or
-tag that matches the locally installed version of Go. If the local
-version "is release.rNN", it searches for "go.rNN". (For an
-installation using Go version "weekly.YYYY-MM-DD", it searches for a
-package version labeled "go.YYYY-MM-DD".)  If the desired version
-cannot be found but others exist with labels in the correct format,
-get retrieves the most recent version before the desired label.
-Finally, if all else fails it retrieves the most recent version of
-the package.\n
+When checking out or updating a package, get looks for a branch or tag
+that matches the locally installed version of Go. The most important
+rule is that if the local installation is running version "go1", get
+searches for a branch or tag named "go1". If no such version exists it
+retrieves the most recent version of the package.\n
 
 For more about specifying packages, see 'go help packages'.

src/cmd/go/get.go の変更

--- a/src/cmd/go/get.go
+++ b/src/cmd/go/get.go
@@ -37,15 +37,11 @@ The -u flag instructs get to use the network to update the named packages
 and their dependencies.  By default, get uses the network to check out
 missing packages but does not use it to look for updates to existing packages.
 
-When checking out or updating a package, get looks for a branch or
-tag that matches the locally installed version of Go. If the local
-version "is release.rNN", it searches for "go.rNN". (For an
-installation using Go version "weekly.YYYY-MM-DD", it searches for a
-package version labeled "go.YYYY-MM-DD".)  If the desired version
-cannot be found but others exist with labels in the correct format,
-get retrieves the most recent version before the desired label.
-Finally, if all else fails it retrieves the most recent version of
-the package.\n
+When checking out or updating a package, get looks for a branch or tag
+that matches the locally installed version of Go. The most important
+rule is that if the local installation is running version "go1", get
+searches for a branch or tag named "go1". If no such version exists it
+retrieves the most recent version of the package.\n
 
 For more about specifying packages, see 'go help packages'.

コアとなるコードの解説

両ファイルで行われている変更は、go getコマンドのドキュメント文字列の更新です。これは、ユーザーがgo help getを実行した際に表示される情報に直接影響します。

削除された部分の解説:

削除されたテキストは、Go 1.0以前のgo getのバージョン選択ロジックを詳細に説明していました。

  • release.rNNやweekly.YYYY-MM-DDといったGoのバージョン形式に対応するタグ（go.rNN、go.YYYY-MM-DD）を探すという記述。
  • 目的のバージョンが見つからない場合に、正しい形式のラベルを持つ他のバージョンの中から「最も新しいバージョン」を取得したり、「最終的にすべて失敗した場合」に「パッケージの最新バージョン」を取得したりするという、複雑なフォールバックメカニズムの記述。

これらの記述は、Go 1.0の安定版リリースを控えて、もはや適切ではなくなりました。Go 1.0以降は、開発版のGoバージョンに厳密に合わせたパッケージバージョンを探す必要性が薄れ、より安定したgo1タグが優先されるべきであるという新しいパラダイムに移行したためです。

追加された部分の解説:

追加されたテキストは、Go 1.0以降のgo getのバージョン選択ロジックを簡潔かつ明確に説明しています。

  • 「ローカルのインストールがバージョンgo1を実行している場合、go getはgo1という名前のブランチまたはタグを探す」という、新しい「最も重要なルール」が導入されました。これは、Go 1.0互換性保証の導入により、go1タグを持つパッケージがGo 1.x環境で動作することが期待されるため、これを最優先で探すという意図を明確にしています。
  • 「そのようなバージョンが存在しない場合、パッケージの最新バージョンを取得する」という、簡素化されたフォールバックロジックが記述されています。これは、go1タグが見つからない場合でも、通常は最新の安定版パッケージを取得すれば問題ないというGo 1.0以降の考え方を反映しています。

この変更は、go getの挙動自体が大きく変わったというよりも、その挙動に関するドキュメントが、Go 1.0のリリースというGo言語の歴史における重要な転換点を反映して更新されたものと理解できます。これにより、ユーザーはGo 1.0以降の環境でgo getがどのように動作するかをより正確に理解できるようになります。

関連リンク

  • Gerrit Change-ID: https://golang.org/cl/5969043
    • これはGoプロジェクトがコードレビューに利用しているGerritシステムにおける変更セットのIDです。このリンクは、このコミットがGerrit上でどのようにレビューされ、承認されたかを示す詳細な情報（レビューコメント、変更履歴など）を提供します。

参考にした情報源リンク

  • Go 1 Release Notes: https://go.dev/doc/go1
    • Go 1.0のリリースノートは、Go 1.0で導入された主要な変更点、特にGo 1互換性保証について理解する上で不可欠な情報源です。
  • Go Modules (Go 1.11以降のパッケージ管理): https://go.dev/blog/using-go-modules
    • このコミットの時点ではGo Modulesは存在しませんでしたが、Go ModulesはGo 1.11で導入されたGoの新しいパッケージ管理システムであり、go getの動作に大きな影響を与えました。このコミットの背景を理解する上で、Go Modules以前のGOPATHベースのパッケージ管理と、その後の進化を知ることは重要です。
  • Goのバージョン管理とリリースプロセスに関する一般的な情報:
    • Goの公式ドキュメントやブログ記事（例: go.dev/blog）は、Goのバージョン管理戦略やリリースプロセスの歴史的背景を理解する上で役立ちます。
    • Goのソースコードリポジトリ（github.com/golang/go）のコミット履歴やドキュメントも、特定の変更の背景を深く掘り下げる際に参照できます。
  • Rob PikeのGoに関する講演や記事:
    • Rob PikeはGo言語の共同開発者の一人であり、彼の講演や記事はGoの設計思想や進化に関する貴重な洞察を提供します。
    • 特にGo 1.0リリース前後の彼の発言は、このコミットの背景にある意図を理解する上で参考になります。
  • Gerrit Code Review System: https://gerrit-review.googlesource.com/
    • GerritはGoogleが開発したオープンソースのコードレビューシステムで、Goプロジェクトもこれを利用しています。Gerritの仕組みを理解することで、golang.org/cl/形式のリンクが何を意味するのかが分かります。

これらの情報源は、このコミットがGo言語の進化のどの段階で行われたのか、そしてそれがGoエコシステム全体にどのような影響を与えたのかを包括的に理解するのに役立ちます。```markdown

[インデックス 12796] ファイルの概要

このコミットは、Go言語のコマンドラインツールであるgoコマンドのドキュメント、特にgo getコマンドに関するタグの扱いについての記述を更新するものです。具体的には、Go 1.0のリリースを控えて、パッケージ取得時のバージョン選択ロジックにおける「go1」タグの優位性を明確にし、それ以前のリリースサイクル（weeklyやrelease.rNN）に関する記述を削除しています。

コミット

commit efb134f8bf8fb22de6e5f0e8ad4e62d8a3671680
Author: Rob Pike <r@golang.org>
Date:   Fri Mar 30 13:07:10 2012 +1100

    cmd/go: update docs about tags for get command
    "go1" dominates. Delete the text about weekly and release.
    We can revisit this once the situation changes.
    
    R=golang-dev, rsc
    CC=golang-dev
    https://golang.org/cl/5969043

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/efb134f8bf8fb22de6e5f0e8ad4e62d8a3671680

元コミット内容

cmd/go: update docs about tags for get command
"go1" dominates. Delete the text about weekly and release.
We can revisit this once the situation changes.

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5969043

変更の背景

このコミットは、Go言語がバージョン1.0の安定版リリースを目前に控えていた時期に行われました。Go 1.0以前は、Goのリリースサイクルは現在とは異なり、weeklyビルドやrelease.rNNといった形式でバージョンが管理されていました。go getコマンドは、パッケージを取得する際に、ローカルのGoバージョンに一致するブランチやタグを探すロジックを持っていました。

しかし、Go 1.0のリリースは、Go言語の安定性と互換性を保証する重要なマイルストーンでした。Go 1.0以降は、APIの互換性が維持されることが強く約束され、これまでの開発版のような頻繁な変更はなくなります。この大きな変化に伴い、go getがパッケージのバージョンを選択する際の優先順位も変更する必要がありました。特に、Go 1.0環境で動作するパッケージは、go1というタグやブランチを持つことで、その互換性を示すことが推奨されるようになりました。

このコミットの目的は、go getのドキュメントを更新し、Go 1.0以降の新しいバージョン選択の振る舞いを正確に反映させることでした。具体的には、go1タグが最も優先されるべきバージョンであることを明確にし、もはや主流ではなくなるweeklyやrelease.rNNといった古いバージョン指定の概念をドキュメントから削除することで、ユーザーの混乱を防ぎ、Go 1.0への移行をスムーズにすることを意図しています。

前提知識の解説

1. go getコマンド

go getは、Go言語のパッケージ管理ツールであり、指定されたパッケージとその依存関係をリモートリポジトリからダウンロードし、ローカルのGOPATH（Go 1.11以降はGo Modulesのキャッシュ）にインストールするコマンドです。開発者が外部ライブラリをプロジェクトに組み込む際に不可欠なツールです。

go getの基本的な動作は以下の通りです。

  • 指定されたインポートパス（例: github.com/user/repo）に対応するリポジトリを特定します。
  • リポジトリをクローンまたはフェッチします。
  • 適切なバージョンのパッケージを選択し、コンパイルしてインストールします。

2. Go言語のバージョン管理（Go 1.0以前と以後）

  • Go 1.0以前: Go言語は活発に開発されており、APIの変更が頻繁に行われていました。この時期のGoのバージョンは、release.rNN（例: release.r60）やweekly.YYYY-MM-DD（例: weekly.2012-03-30）といった形式で識別されていました。go getは、ローカルのGoバージョンがこれらの形式に一致する場合、対応するタグやブランチを持つパッケージを探し、互換性のあるバージョンを取得しようと試みました。これは、開発版Goの特定のバージョンで動作するパッケージを確実に入手するための仕組みでした。
  • Go 1.0以降: 2012年3月28日にリリースされたGo 1.0は、Go言語の安定版としての最初のリリースであり、Go 1互換性保証が導入されました。これは、Go 1.xの範囲内では、既存のGo 1プログラムが将来のGo 1.xリリースでも動作し続けることを保証するものです。この保証により、Goエコシステムは安定し、開発者は安心してライブラリやアプリケーションを構築できるようになりました。 Go 1.0のリリースに伴い、パッケージのバージョン選択ロジックも簡素化され、安定版Go 1で動作するパッケージはgo1というタグを持つことが推奨されるようになりました。これにより、go getは、ローカルのGoがGo 1.xである場合、まずgo1タグを持つパッケージを探すようになります。

3. タグとブランチ

Gitなどのバージョン管理システムにおいて、

  • タグ: 特定のコミットに永続的な名前（例: v1.0.0, go1）を付けるものです。主にリリースバージョンや重要なマイルストーンを示すために使用されます。タグは通常、変更されません。
  • ブランチ: 開発の並行ラインです。新しい機能の開発やバグ修正のために作成され、最終的にはメインブランチにマージされます。

go getは、これらのタグやブランチを利用して、特定のGoバージョンと互換性のあるパッケージのソースコードを取得します。

技術的詳細

このコミットの技術的詳細は、go getコマンドがパッケージのバージョンを選択する際の内部ロジックと、そのロジックがユーザーにどのように伝えられるかというドキュメントの側面の両方に影響を与えます。

Go 1.0以前のgo getは、ローカルのGoインストールがrelease.rNNやweekly.YYYY-MM-DDのような開発版のバージョンである場合、リモートリポジトリ内でそれに対応するタグやブランチ（例: go.rNN、go.YYYY-MM-DD）を探し、そのバージョンを取得しようと試みました。これは、Go言語自体がまだ活発に開発中で、APIが頻繁に変更されていた時期には理にかなった挙動でした。特定の開発版Goで動作するパッケージを確実に入手するためには、そのGoバージョンに合わせたパッケージのバージョンを取得する必要があったからです。

しかし、Go 1.0のリリースにより、この状況は根本的に変わりました。Go 1.0は安定版であり、Go 1互換性保証が導入されたため、Go 1.xの範囲内ではAPIの互換性が維持されることになりました。これにより、パッケージ開発者は、Go 1.0以降のどのGoバージョンでも動作するパッケージに対して、単一のgo1タグを付けることで、その互換性を示すことができるようになりました。

このコミットは、この新しい現実を反映するために、go getのドキュメントと、おそらくは内部的なバージョン選択ロジック（ドキュメントの変更がコードの変更と同期しているため）を更新しています。

変更のポイント:

  1. go1タグの優位性: ドキュメントは、「ローカルのインストールがバージョンgo1を実行している場合、go getはgo1という名前のブランチまたはタグを探す」という新しい最も重要なルールを明確にしています。これは、Go 1.0以降の環境では、go1タグを持つパッケージが優先的に選択されることを意味します。
  2. 古いバージョン指定の削除: release.rNNやweekly.YYYY-MM-DDといった古い形式のバージョン指定に関する記述がドキュメントから削除されました。これは、これらの形式がGo 1.0以降のGoエコシステムではもはや主要な役割を果たさないことを示しています。
  3. フォールバックロジックの簡素化: 以前は、特定のバージョンが見つからない場合に「最も近いバージョン」や「最新バージョン」を取得するという複雑なフォールバックロジックが記述されていましたが、変更後は「そのようなバージョンが存在しない場合、パッケージの最新バージョンを取得する」というシンプルな記述になっています。これは、go1タグが優先され、それが見つからない場合は最新版で十分であるというGo 1.0以降の考え方を反映しています。

この変更は、GoエコシステムがGo 1.0の安定性に基づいて進化していく上で、go getがどのようにパッケージのバージョンを解決するかについてのユーザーの理解を簡素化し、明確にする上で非常に重要でした。

コアとなるコードの変更箇所

このコミットでは、以下の2つのファイルが変更されています。

  1. src/cmd/go/doc.go
  2. src/cmd/go/get.go

両ファイルで同様の変更が行われており、go getコマンドのヘルプドキュメントと、おそらくは内部的なgetコマンドのドキュメント文字列が更新されています。

src/cmd/go/doc.go の変更

--- a/src/cmd/go/doc.go
+++ b/src/cmd/go/doc.go
@@ -227,15 +227,11 @@ The -u flag instructs get to use the network to update the named packages
 and their dependencies.  By default, get uses the network to check out
 missing packages but does not use it to look for updates to existing packages.
 
-When checking out or updating a package, get looks for a branch or
-tag that matches the locally installed version of Go. If the local
-version "is release.rNN", it searches for "go.rNN". (For an
-installation using Go version "weekly.YYYY-MM-DD", it searches for a
-package version labeled "go.YYYY-MM-DD".)  If the desired version
-cannot be found but others exist with labels in the correct format,
-get retrieves the most recent version before the desired label.
-Finally, if all else fails it retrieves the most recent version of
-the package.\n
+When checking out or updating a package, get looks for a branch or tag
+that matches the locally installed version of Go. The most important
+rule is that if the local installation is running version "go1", get
+searches for a branch or tag named "go1". If no such version exists it
+retrieves the most recent version of the package.\n
 
 For more about specifying packages, see 'go help packages'.

src/cmd/go/get.go の変更

--- a/src/cmd/go/get.go
+++ b/src/cmd/go/get.go
@@ -37,15 +37,11 @@ The -u flag instructs get to use the network to update the named packages
 and their dependencies.  By default, get uses the network to check out
 missing packages but does not do it to look for updates to existing packages.
 
-When checking out or updating a package, get looks for a branch or
-tag that matches the locally installed version of Go. If the local
-version "is release.rNN", it searches for "go.rNN". (For an
-installation using Go version "weekly.YYYY-MM-DD", it searches for a
-package version labeled "go.YYYY-MM-DD".)  If the desired version
-cannot be found but others exist with labels in the correct format,
-get retrieves the most recent version before the desired label.
-Finally, if all else fails it retrieves the most recent version of
-the package.\n
+When checking out or updating a package, get looks for a branch or tag
+that matches the locally installed version of Go. The most important
+rule is that if the local installation is running version "go1", get
+searches for a branch or tag named "go1". If no such version exists it
+retrieves the most recent version of the package.\n
 
 For more about specifying packages, see 'go help packages'.

コアとなるコードの解説

両ファイルで行われている変更は、go getコマンドのドキュメント文字列の更新です。これは、ユーザーがgo help getを実行した際に表示される情報に直接影響します。

削除された部分の解説:

削除されたテキストは、Go 1.0以前のgo getのバージョン選択ロジックを詳細に説明していました。

  • release.rNNやweekly.YYYY-MM-DDといったGoのバージョン形式に対応するタグ（go.rNN、go.YYYY-MM-DD）を探すという記述。
  • 目的のバージョンが見つからない場合に、正しい形式のラベルを持つ他のバージョンの中から「最も新しいバージョン」を取得したり、「最終的にすべて失敗した場合」に「パッケージの最新バージョン」を取得したりするという、複雑なフォールバックメカニズムの記述。

これらの記述は、Go 1.0の安定版リリースを控えて、もはや適切ではなくなりました。Go 1.0以降は、開発版のGoバージョンに厳密に合わせたパッケージバージョンを探す必要性が薄れ、より安定したgo1タグが優先されるべきであるという新しいパラダイムに移行したためです。

追加された部分の解説:

追加されたテキストは、Go 1.0以降のgo getのバージョン選択ロジックを簡潔かつ明確に説明しています。

  • 「ローカルのインストールがバージョンgo1を実行している場合、go getはgo1という名前のブランチまたはタグを探す」という、新しい「最も重要なルール」が導入されました。これは、Go 1.0互換性保証の導入により、go1タグを持つパッケージがGo 1.x環境で動作することが期待されるため、これを最優先で探すという意図を明確にしています。
  • 「そのようなバージョンが存在しない場合、パッケージの最新バージョンを取得する」という、簡素化されたフォールバックロジックが記述されています。これは、go1タグが見つからない場合でも、通常は最新の安定版パッケージを取得すれば問題ないというGo 1.0以降の考え方を反映しています。

この変更は、go getの挙動自体が大きく変わったというよりも、その挙動に関するドキュメントが、Go 1.0のリリースというGo言語の歴史における重要な転換点を反映して更新されたものと理解できます。これにより、ユーザーはGo 1.0以降の環境でgo getがどのように動作するかをより正確に理解できるようになります。

関連リンク

  • Gerrit Change-ID: https://golang.org/cl/5969043
    • これはGoプロジェクトがコードレビューに利用しているGerritシステムにおける変更セットのIDです。このリンクは、このコミットがGerrit上でどのようにレビューされ、承認されたかを示す詳細な情報（レビューコメント、変更履歴など）を提供します。

参考にした情報源リンク

  • Go 1 Release Notes: https://go.dev/doc/go1
    • Go 1.0のリリースノートは、Go 1.0で導入された主要な変更点、特にGo 1互換性保証について理解する上で不可欠な情報源です。
  • Go Modules (Go 1.11以降のパッケージ管理): https://go.dev/blog/using-go-modules
    • このコミットの時点ではGo Modulesは存在しませんでしたが、Go ModulesはGo 1.11で導入されたGoの新しいパッケージ管理システムであり、go getの動作に大きな影響を与えました。このコミットの背景を理解する上で、Go Modules以前のGOPATHベースのパッケージ管理と、その後の進化を知ることは重要です。
  • Goのバージョン管理とリリースプロセスに関する一般的な情報:
    • Goの公式ドキュメントやブログ記事（例: go.dev/blog）は、Goのバージョン管理戦略やリリースプロセスの歴史的背景を理解する上で役立ちます。
    • Goのソースコードリポジトリ（github.com/golang/go）のコミット履歴やドキュメントも、特定の変更の背景を深く掘り下げる際に参照できます。
  • Rob PikeのGoに関する講演や記事:
    • Rob PikeはGo言語の共同開発者の一人であり、彼の講演や記事はGoの設計思想や進化に関する貴重な洞察を提供します。
    • 特にGo 1.0リリース前後の彼の発言は、このコミットの背景にある意図を理解する上で参考になります。
  • Gerrit Code Review System: https://gerrit-review.googlesource.com/
    • GerritはGoogleが開発したオープンソースのコードレビューシステムで、Goプロジェクトもこれを利用しています。Gerritの仕組みを理解することで、golang.org/cl/形式のリンクが何を意味するのかが分かります。

これらの情報源は、このコミットがGo言語の進化のどの段階で行われたのか、そしてそれがGoエコシステム全体にどのような影響を与えたのかを包括的に理解するのに役立ちます。