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

このコミットは、Go言語のバージョン1（Go 1）のリリースに伴い、将来のGoプログラムとの互換性に関する公式ドキュメント doc/go1compat.html を追加するものです。このドキュメントは、Go 1が言語仕様と標準ライブラリのコアAPIの安定した基盤となることを定義し、Go 1仕様に準拠して書かれたプログラムが、将来のGo 1のポイントリリース（Go 1.1, Go 1.2など）においても変更なしでコンパイルおよび実行され続けることを意図しています。

コミット

commit 68794e7910e2db051b5e1c9a17bc358375fcf157
Author: Rob Pike <r@golang.org>
Date:   Thu Feb 9 09:42:40 2012 +1100

    doc: new document about compatibility of releases
    The doc is not linked anywhere yet; that will come later.
    
    R=golang-dev, adg, gri, rsc, edsrzf
    CC=golang-dev
    https://golang.org/cl/5647050

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

https://github.com/golang/go/commit/68794e7910e2db051b5e1c9a17bc358375fcf157

元コミット内容

このコミットは、Go言語のリリース互換性に関する新しいドキュメントを追加するものです。具体的には、doc/go1compat.html というファイルが新規作成され、Go 1リリース以降の言語および標準ライブラリの互換性ポリシーについて記述されています。コミットメッセージには、このドキュメントがまだどこからもリンクされていないが、後でリンクされる予定であることが明記されています。これは、Go 1の正式リリースに向けて、互換性に関する重要な情報提供の準備を進めている段階であることを示唆しています。

変更の背景

Go言語は、2009年の公開以来、急速に進化を続けていました。しかし、初期のバージョンでは言語仕様や標準ライブラリのAPIが頻繁に変更され、既存のコードが新しいバージョンで動作しなくなる「破壊的変更」が発生することがありました。これは、Go言語の採用を検討する開発者や企業にとって大きな懸念事項でした。

Go 1のリリースは、Go言語が成熟し、安定したプラットフォームとして確立されるための重要な節目でした。この安定性を保証し、開発者が安心してGo言語を採用できるようにするためには、将来のバージョンアップにおける互換性の方針を明確に定める必要がありました。

doc/go1compat.html の追加は、この互換性保証のコミットメントを公式に表明するためのものです。Go 1が言語仕様とコアAPIの安定した基盤を提供し、Go 1に準拠して書かれたプログラムが将来にわたって動作し続けることを約束することで、Goエコシステムの成長を促進し、より多くの開発者やプロジェクトがGo言語を採用する後押しとなることを目的としています。

前提知識の解説

Go 1とは

Go 1は、Go言語の最初のメジャーリリースであり、2012年3月28日に公開されました。Go 1のリリースは、Go言語の仕様と標準ライブラリのAPIを安定させることを目的としていました。これにより、Go 1で書かれたプログラムは、将来のGoのバージョン（Go 1.x）でも互換性が維持され、変更なしで動作することが保証されるようになりました。これは、言語の採用とエコシステムの成長にとって非常に重要なマイルストーンでした。

互換性 (Compatibility)

ソフトウェア開発における互換性とは、あるシステムやコンポーネントが、別のシステムやコンポーネント、またはその将来のバージョンと問題なく連携して動作する能力を指します。Go言語の文脈では、主に以下の2つの側面が重要になります。

• ソース互換性 (Source Compatibility): 既存のソースコードが、新しいバージョンのコンパイラやライブラリで、変更なしにコンパイルできることを指します。Go 1では、このソース互換性が強く保証されています。
• バイナリ互換性 (Binary Compatibility): コンパイル済みのバイナリファイルが、新しいバージョンのライブラリなどとリンクして動作できることを指します。Go言語では、Go 1のポイントリリース間でのバイナリ互換性は保証されていません。これは、コンパイル済みのパッケージを新しいリリースとリンクするためには、Goのソースコードを再コンパイルする必要があることを意味します。

ポイントリリース (Point Releases)

Go 1.1, Go 1.2, Go 1.3 のように、メジャーバージョン（この場合はGo 1）の後に続くマイナーなバージョンアップを指します。これらのリリースでは、通常、バグ修正、パフォーマンス改善、新しい機能の追加が行われますが、Go 1の互換性ポリシーに則り、既存のGo 1プログラムを破壊しないように配慮されます。

API安定性 (API Stability)

API安定性とは、アプリケーションプログラミングインターフェース（API）が、時間の経過とともに変更されず、既存のソフトウェアが引き続きそれを利用できることを指します。Go 1では、標準パッケージのコアAPIについて高い安定性が約束されており、新しいパッケージや機能が追加されることはあっても、既存のGo 1コードを破壊する形での変更は行われないとされています。

技術的詳細

doc/go1compat.html ドキュメントでは、Go 1の互換性に関する基本的な約束と、ごく稀に互換性が損なわれる可能性のある例外的なケースについて詳細に説明しています。

Go 1の互換性保証の原則

• 言語仕様の安定性: Go 1は言語の仕様を定義し、この仕様に準拠して書かれたプログラムは、Go 1のライフタイムを通じて変更なしでコンパイルおよび実行され続けることが意図されています。
• コアAPIの安定性: Go 1は、標準パッケージのコアAPIのセットも定義しています。これらのAPIは成長し、新しいパッケージや機能が追加されることはあっても、既存のGo 1コードを破壊する形での変更は行われません。
• ソースレベルの互換性: 互換性はソースコードレベルで保証されます。コンパイル済みパッケージのバイナリ互換性は、リリース間で保証されません。ポイントリリース後には、新しいリリースとリンクするためにGoのソースコードを再コンパイルする必要があります。

互換性が損なわれる可能性のある例外

ドキュメントでは、ほとんどのプログラムで互換性が維持されると期待されるものの、将来の変更によってプログラムが動作しなくなる可能性のある、ごく稀なケースについても言及しています。これらはすべて可能性は低いものの、記録しておく価値があるとされています。

1. セキュリティ (Security): 仕様または実装におけるセキュリティ問題が明らかになり、その解決のために互換性を破壊する必要がある場合。Goチームは、このようなセキュリティ問題に対処する権利を留保しています。
2. 未定義の動作 (Unspecified behavior): Goの仕様は言語のほとんどのプロパティについて明示的ですが、一部未定義の側面があります。このような未定義の動作に依存するプログラムは、将来のリリースで動作しなくなる可能性があります。
3. 仕様の誤り (Specification errors): 仕様の不整合や不完全性に対処する必要が生じた場合、その解決が既存のプログラムの意味や合法性に影響を与える可能性があります。Goチームは、実装の更新を含め、このような問題に対処する権利を留保しています。セキュリティ問題を除き、仕様に対する互換性のない変更は行われません。
4. バグ (Bugs): コンパイラやライブラリに仕様に違反するバグがあり、そのバグのある動作に依存するプログラムは、バグが修正された場合に動作しなくなる可能性があります。Goチームは、このようなバグを修正する権利を留保しています。
5. 構造体リテラル (Struct literals): 将来のポイントリリースで機能を追加するために、APIの公開された構造体にフィールドを追加する必要がある場合があります。このような変更後、これらの型の値を生成するためにタグなし構造体リテラル（例: pkg.T{3, "x"}）を使用するコードはコンパイルに失敗します。しかし、タグ付きリテラル（例: pkg.T{A: 3, B: "x"}）を使用するコードは、このような変更後もコンパイルされ続けます。このため、ドキュメントでは、別のパッケージで定義された型を持つ複合リテラルには、タグ付き表記を使用することを推奨しています。

これらの可能性について、Goチームは可能な限り、既存のコードに影響を与えずに仕様、コンパイラ、またはライブラリを更新するよう努めると述べられています。

その他の考慮事項

• ポイントリリース間の互換性: Go 1.2で動作するコードは、Go 1.2.1, Go 1.3, Go 1.4などと互換性がありますが、Go 1.2で追加された機能を使用している可能性があるため、Go 1.1とは必ずしも互換性があるとは限りません。
• 未リリース機能の非互換性: ソースリポジトリには存在するが、番号付きバイナリリリースの一部ではない、リリース間で追加された機能は活発に開発中であり、互換性は保証されません。
• パフォーマンス: 正確性の問題ではないものの、プログラムのパフォーマンスは、依存するコンパイラやライブラリの実装の変更によって影響を受ける可能性があります。リリース間の特定のプログラムのパフォーマンスについては保証されません。
• サブリポジトリ: code.google.com/p/go.net のようなメインのGoツリーのサブリポジトリのコードは、より緩い互換性要件の下で開発される可能性があります。ただし、サブリポジトリは、Go 1のポイントリリースと互換性のあるバージョンを識別するために適切にタグ付けされます。
• ツール: Goツールチェーン（コンパイラ、リンカ、ビルドツールなど）は活発に開発中であり、動作が変更される可能性があります。これは、ツールの場所やプロパティに依存するスクリプトが、ポイントリリースによって壊れる可能性があることを意味します。

これらの注意点があるものの、Go 1はGoとそのエコシステムの発展のための確固たる基盤となると信じられています。

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

このコミットで追加されたコアとなるコードは、doc/go1compat.html ファイル全体です。

<!--{
	"Title": "Go 1 and the Future of Go Programs"
}-->

<h2 id="introduction">Introduction</h2>
<p>
The release of Go version 1, Go 1 for short, is a major milestone
in the development of the language. Go 1 is a stable platform for
the growth of programs and projects written in Go.
</p>

<p>
Go 1 defines two things: first, the specification of the language;
and second, the specification of a set of core APIs, the "standard
packages" of the Go library. The Go 1 release includes their
implementation in the form of two compiler suites (gc and gccgo),
and the core libraries themselves.
</p>

<p>
It is intended that programs written to the Go 1 specification will
continue to compile and run correctly, unchanged, over the lifetime
of that specification. At some indefinite point, a Go 2 specification
may arise, but until that time, Go programs that work today should
continue to work even as future "point" releases of Go 1 arise (Go
1.1, Go 1.2, etc.).
</p>

<p>
Compatibility is at the source level. Binary compatibility for
compiled packages is not guaranteed between releases. After a point
release, Go source will need to be recompiled to link against the
new release.
</p>

<p>
The APIs may grow, acquiring new packages and features, but not in
a way that breaks existing Go 1 code.
</p>

<h2 id="expectations">Expectations</h2>

<p>
Although we expect that the vast majority of programs will maintain
this compatibility over time, it is impossible to guarantee that
no future change will break any program. This document is an attempt
to set expectations for the compatibility of Go 1 software in the
future. There are a number of ways in which a program that compiles
and runs today may fail to do so after a future point release. They
are all unlikely but worth recording.
</p>

<ul>
<li>
Security. A security issue in the specification or implementation
may come to light whose resolution requires breaking compatibility.
We reserve the right to address such security issues.
</li>

<li>
Unspecified behavior. The Go specification tries to be explicit
about most properties of the language, but there are some aspects
that are undefined. Programs that depend on such unspecified behavior
may break in future releases.
</li>

<li>
Specification errors. If it becomes necessary to address an
inconsistency or incompleteness in the specification, resolving the
issue could affect the meaning or legality of existing programs.
We reserve the right to address such issues, including updating the
implementations. Except for security issues, no incompatible changes
to the specification would be made.
</li>

<li>
Bugs. If a compiler or library has a bug that violates the
specification, a program that depends on the buggy behavior may
break if the bug is fixed. We reserve the right to fix such bugs.
</li>

<li>
Struct literals. For the addition of features in later point
releases, it may be necessary to add fields to exported structs in
the API. Code that uses untagged struct literals (such as pkg.T{3,
"x"}) to create values of these types would fail to compile after
such a change. However, code that uses tagged literals (pkg.T{A:
3, B: "x"}) will continue to compile after such a change. We will
update such data structures in a way that allows tagged struct
literals to remain compatible, although untagged literals may fail
to compile. (There are also more intricate cases involving nested
data structures or interfaces, but they have the same resolution.)
We therefore recommend that composite literals whose type is defined
in a separate package should use the tagged notation.
</li>

</ul>

<p>
Of course, for all of these possibilities, should they arise, we
would endeavor whenever feasible to update the specification,
compilers, or libraries without affecting existing code.
</p>

<p>
These same considerations apply to successive point releases. For
instance, code that runs under Go 1.2 should be compatible with Go
1.2.1, Go 1.3, Go 1.4, etc., although not necessarily with Go 1.1
since it may use features added only in Go 1.2
</p>

<p>
Features added between releases, available in the source repository
but not part of the numbered binary releases, are under active
development. No promise of compatibility is made for software using
such features until they have been released.
</p>

<p>
Finally, although it is not a correctness issue, it is possible
that the performance of a program may be affected by
changes in the implementation of the compilers or libraries upon
which it depends.
No guarantee can be made about the performance of a
given program between releases.
</p>

<p>
Although these expectations apply to Go 1 itself, we hope similar
considerations would be made for the development of externally
developed software based on Go 1.
</p>

<h2 id="subrepos">Sub-repositories</h2>

<p>
Code in sub-repositories of the main go tree, such as
<a href="http://code.google.com/p/go.net">code.google.com/p/go.net</a>,
may be developed under
looser compatibility requirements. However, the sub-repositories
will be tagged as appropriate to identify versions that are compatible
with the Go 1 point releases.
</p>

<h2 id="tools">Tools</h2>

<p>
Finally, the Go tool chain (compilers, linkers, build tools, and so
on) are under active development and may change behavior. This
means, for instance, that scripts that depend on the location and
properties of the tools may be broken by a point release.
</p>

<p>
These caveats aside, we believe that Go 1 will be a firm foundation
for the development of Go and its ecosystem.
</p>

コアとなるコードの解説

追加された doc/go1compat.html は、Go 1の互換性に関する公式な指針を示すHTMLドキュメントです。

• タイトルとメタデータ: ドキュメントの冒頭には、<!--{"Title": "Go 1 and the Future of Go Programs"}--> という形式でタイトルが埋め込まれています。これは、Goのドキュメント生成ツールがタイトルを抽出するために使用するメタデータです。
• Introduction (導入): Go 1が言語開発における主要なマイルストーンであり、Goで書かれたプログラムやプロジェクトの成長のための安定したプラットフォームであることを説明しています。Go 1が言語仕様と標準パッケージのコアAPIの仕様を定義し、その実装（gcおよびgccgoコンパイラスイートとコアライブラリ）を含むことを述べています。Go 1仕様に準拠するプログラムは、その仕様のライフタイムを通じて変更なしでコンパイルおよび実行され続けることが意図されており、将来のGo 1のポイントリリース（Go 1.1, Go 1.2など）でも動作し続けることが期待されています。互換性はソースレベルであり、バイナリ互換性はリリース間で保証されないことが明記されています。APIは成長する可能性があるが、既存のGo 1コードを破壊する形では行われないとされています。
• Expectations (期待): ほとんどのプログラムで互換性が維持されると期待されるものの、将来の変更によってプログラムが動作しなくなる可能性のある、ごく稀なケースについて説明しています。具体的には、セキュリティ問題、未定義の動作、仕様の誤り、バグ、そして構造体リテラルの使用方法（タグなしリテラルが将来的にコンパイルに失敗する可能性があり、タグ付きリテラルが推奨される）が挙げられています。これらの可能性が生じた場合でも、Goチームは可能な限り既存のコードに影響を与えずに仕様、コンパイラ、またはライブラリを更新するよう努めると述べられています。また、Go 1.2で動作するコードはGo 1.2.1, Go 1.3などと互換性があるが、Go 1.1とは必ずしも互換性がないこと、未リリースの機能には互換性の約束がないこと、パフォーマンスはリリース間で保証されないことにも触れています。
• Sub-repositories (サブリポジトリ): code.google.com/p/go.net のようなメインのGoツリーのサブリポジトリのコードは、より緩い互換性要件の下で開発される可能性があるが、Go 1のポイントリリースと互換性のあるバージョンを識別するために適切にタグ付けされることが説明されています。
• Tools (ツール): Goツールチェーン（コンパイラ、リンカ、ビルドツールなど）は活発に開発中であり、動作が変更される可能性があるため、ツールの場所やプロパティに依存するスクリプトがポイントリリースによって壊れる可能性があると警告しています。
• 結論: これらの注意点があるものの、Go 1はGoとそのエコシステムの発展のための確固たる基盤となると信じている、と締めくくられています。

このドキュメントは、Go言語の安定性と将来性に対するGoチームの強いコミットメントを示すものであり、Go言語を採用する開発者にとって非常に重要な情報源となります。

関連リンク

• Go 1 Release Notes: https://go.dev/doc/go1 (Go 1の公式リリースノート)

参考にした情報源リンク

• Go 1 and the Future of Go Programs (このコミットで追加されたドキュメントの最終版): https://go.dev/doc/go1compat
• Go 1 Release Announcement: https://go.dev/blog/go1
• Wikipedia - Go (programming language): https://en.wikipedia.org/wiki/Go_(programming_language)