Go 1 and the Future of Go Programs

Introduction

The release of Go version 1, Go 1 for short, is a major milestonein the development of the language. Go 1 is a stable platform forthe growth of programs and projects written in Go.

Go 1 defines two things: first, the specification of the language;and second, the specification of a set of core APIs, the "standardpackages" of the Go library. The Go 1 release includes theirimplementation in the form of two compiler suites (gc and gccgo),and the core libraries themselves.

It is intended that programs written to the Go 1 specification willcontinue to compile and run correctly, unchanged, over the lifetimeof that specification. At some indefinite point, a Go 2 specificationmay arise, but until that time, Go programs that work today shouldcontinue to work even as future "point" releases of Go 1 arise (Go1.1, Go 1.2, etc.).

Compatibility is at the source level. Binary compatibility forcompiled packages is not guaranteed between releases. After a pointrelease, Go source will need to be recompiled to link against thenew release.

The APIs may grow, acquiring new packages and features, but not ina way that breaks existing Go 1 code.

Expectations

Although we expect that the vast majority of programs will maintainthis compatibility over time, it is impossible to guarantee thatno future change will break any program. This document is an attemptto set expectations for the compatibility of Go 1 software in thefuture. There are a number of ways in which a program that compilesand runs today may fail to do so after a future point release. Theyare all unlikely but worth recording.

Security. A security issue in the specification or implementationmay come to light whose resolution requires breaking compatibility.We reserve the right to address such security issues.
Unspecified behavior. The Go specification tries to be explicitabout most properties of the language, but there are some aspectsthat are undefined. Programs that depend on such unspecified behaviormay break in future releases.
Specification errors. If it becomes necessary to address aninconsistency or incompleteness in the specification, resolving theissue could affect the meaning or legality of existing programs.We reserve the right to address such issues, including updating theimplementations. Except for security issues, no incompatible changesto the specification would be made.
Bugs. If a compiler or library has a bug that violates thespecification, a program that depends on the buggy behavior maybreak if the bug is fixed. We reserve the right to fix such bugs.
Struct literals. For the addition of features in later pointreleases, it may be necessary to add fields to exported structs inthe API. Code that uses unkeyed struct literals (such as pkg.T{3,"x"}) to create values of these types would fail to compile aftersuch a change. However, code that uses keyed literals (pkg.T{A:3, B: "x"}) will continue to compile after such a change. We willupdate such data structures in a way that allows keyed structliterals to remain compatible, although unkeyed literals may failto compile. (There are also more intricate cases involving nesteddata structures or interfaces, but they have the same resolution.)We therefore recommend that composite literals whose type is definedin a separate package should use the keyed notation.
Methods. As with struct fields, it may be necessary to add methodsto non-interface types.Under some circumstances, such as when the type is embedded ina struct along with another type,the addition of the new method may breakthe struct by creating a conflict with an existing method of the otherembedded type.We cannot protect against this rare case and do not guarantee compatibilityshould it arise.
Dot imports. If a program imports a standard packageusingimport . "path", additional names defined in theimported package in future releases may conflict with other namesdefined in the program. We do not recommend the use ofimport .outside of tests, and using it may cause a program to failto compile in future releases.
Use of packageunsafe. Packages that importunsafemay depend on internal properties of the Go implementation.We reserve the right to make changes to the implementationthat may break such programs.

Of course, for all of these possibilities, should they arise, wewould endeavor whenever feasible to update the specification,compilers, or libraries without affecting existing code.

These same considerations apply to successive point releases. Forinstance, code that runs under Go 1.2 should be compatible with Go1.2.1, Go 1.3, Go 1.4, etc., although not necessarily with Go 1.1since it may use features added only in Go 1.2

Features added between releases, available in the source repositorybut not part of the numbered binary releases, are under activedevelopment. No promise of compatibility is made for software usingsuch features until they have been released.

Finally, although it is not a correctness issue, it is possiblethat the performance of a program may be affected bychanges in the implementation of the compilers or libraries uponwhich it depends.No guarantee can be made about the performance of agiven program between releases.

Although these expectations apply to Go 1 itself, we hope similarconsiderations would be made for the development of externallydeveloped software based on Go 1.

Sub-repositories

Code in sub-repositories of the main go tree, such asgolang.org/x/net,may be developed underlooser compatibility requirements. However, the sub-repositorieswill be tagged as appropriate to identify versions that are compatiblewith the Go 1 point releases.

Operating systems

It is impossible to guarantee long-term compatibility with operatingsystem interfaces, which are changed by outside parties.Thesyscall packageis therefore outside the purview of the guarantees made here.As of Go version 1.4, thesyscall package is frozen.Any evolution of the system call interface must be supported elsewhere,such as in thego.sys subrepository.For details and background, seethis document.

Tools

Finally, the Go toolchain (compilers, linkers, build tools, and soon) is under active development and may change behavior. Thismeans, for instance, that scripts that depend on the location andproperties of the tools may be broken by a point release.

These caveats aside, we believe that Go 1 will be a firm foundationfor the development of Go and its ecosystem.