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.
Go 版本 1（简称 Go 1）的发布，在该语言的开发历程中是一个重要的里程碑。 对于用Go编写的程序与项目的成长来说，Go 1是一个稳定的平台。
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.
Go 1定义了两件事：第一，是该语言的规范；第二，是核心API集的规范。 Go 1的发布包含了两组编译器套件（gc与gccgo）的实现，以及它们的核心库。
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.).
其目的在于，Go 1规范编写的程序将无需改变而继续正确地编译并运行， 直到该规范的生命周期结束。在将来的某个时刻，Go2规范将会出现， 但直到那一刻以前，现今能够工作的Go程序将继续工作，即便在未来Go 1的“点”发行版出现时（Go 1.1、Go 1.2等等。）。
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.
The APIs may grow, acquiring new packages and features, but not in a way that breaks existing Go 1 code.
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.
尽管我们希望尽可能地保持绝大多数程序的兼容性， 但要保证将来的改变不会破坏任何程序是不可能的。本文档试图整理出将来 Go 1 软件预期的兼容性。在未来的点发行版发布后，现今程序某些方面的编译与运行可能会失败。 尽管它们不太可能发生，但仍值得记录。
import . "path", additional names defined in the imported package in future releases may conflict with other names defined in the program. We do not recommend the use of
import .outside of tests, and using it may cause a program to fail to compile in future releases.
import . "path"导入标准包，在将来的发行版中， 已导入包中添加的名字可能会与该程序中定义的其它名字冲突。我们不建议在测试之外 使用
unsafe. Packages that import
unsafemay depend on internal properties of the Go implementation. We reserve the right to make changes to the implementation that may break such programs.
unsafe的包可能依赖 Go 实现的内部属性。我们保留对该实现作出更改的权利，因此这可能会破坏使用该包的程序。
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.
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
有一些考虑适用于连续的点发行版。例如，在Go 1.2下运行的代码应当与Go 1.2.1、Go 1.3、Go 1.4等等相兼容，尽管没必要与Go 1.1相兼容， 但也会只在Go 1.2中添加一些特性来保证兼容性。
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.
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.
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.
尽管这些预期应用于Go 1本身，但我们希望相似的考虑对基于Go 1的外部开发软件也适用。
Code in sub-repositories of the main go tree, such as golang.org/x/net, 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.
主Go源码树子仓库中的代码，例如 code.google.com/p/go.net， 在更宽松的兼容性需求下开发。然而，子仓库将适当地标记为与Go 1的点发行相兼容的相同版本。
It is impossible to guarantee long-term compatibility with operating
system interfaces, which are changed by outside parties.
is therefore outside the purview of the guarantees made here.
As of Go version 1.4, the
syscall package is frozen.
Any evolution of the system call interface must be supported elsewhere,
such as in the
For details and background, see
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.
These caveats aside, we believe that Go 1 will be a firm foundation for the development of Go and its ecosystem.