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

1 files changed, 157 insertions, 0 deletions

diff --git a/doc/go1compat.html b/doc/go1compat.html
new file mode 100644
index 0000000000..3804634f5d
--- /dev/null
+++ b/doc/go1compat.html
@@ -0,0 +1,157 @@
+<!--{
+	"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>