Go · Version History
Every release of Go.
I track every Go release here — from the open-source release in November 2009 and the Go 1 contract in March 2012 through the current line — with ship dates, the headline changes per version, and links to the upstream release notes. Go ships on a strict six-month cadence (February and August) and holds itself to the Go 1 compatibility promise: code written to the Go 1 spec is meant to keep compiling and running, release after release.
Current: Go 1.26.0 — released February 2026.
Current as of June 2026.
Born at Google (2007) and open-sourced (November 2009)
Go began at Google in 2007 as a reaction to the day-to-day friction of building large systems in C++ and Java: glacial build times, sprawling dependency graphs, and concurrency primitives that felt bolted on. Its three original authors — Robert Griesemer, Rob Pike, and Ken Thompson — set out to design a language that compiled fast, read clearly, and made concurrency a first-class idea rather than a library. The result keeps a deliberately small feature set, leans on goroutines and channels for concurrency, and treats fast compilation as a design constraint, not an afterthought.
Go was announced and open-sourced on November 10, 2009. The mascot — the Go gopher, drawn by Renée French — arrived with it and became one of the most recognizable logos in the language world. For its first two and a half years Go was a moving target: the pre-1.0 releases changed the language and standard library freely, which made the eventual stabilization all the more consequential.
The Go 1 contract (March 2012)
Go 1.0 shipped on March 28, 2012, and with it came the document that has shaped every release since: the Go 1 compatibility promise. The guarantee is precise. Source code written to the Go 1 specification is intended to compile and run unchanged on every later Go 1.x release. The promise is at the source level — binaries are not portable across versions, so you recompile — but you should not have to edit working code to move forward a version.
What the promise reserves is as important as what it grants. The team may break compatibility to fix security problems, to correct cases where the specification and the implementation disagree, and for any program that reaches into package unsafe and depends on implementation details it was never promised. Everything else is meant to keep working. That single contract — documented at go.dev/doc/go1compat — is why upgrading the Go toolchain across a decade of releases is, for most codebases, an uneventful afternoon rather than a migration project. It is the load-bearing reason the ecosystem trusts the upgrade path.
The modules saga
For its first several years Go had no built-in dependency versioning. Code lived under a single GOPATH workspace, imports resolved by directory path, and there was no notion of “which version” of a dependency you were building against. That worked at small scale and broke painfully at large scale, which is why the community filled the gap with tools — godep, glide, and eventually the semi-official dep, which used a manifest-and-lock model familiar from other ecosystems.
The decisive turn came from Russ Cox, whose vgo proposal argued for a different model built on minimal version selection and an import-compatibility rule. It was controversial — it set aside much of dep's design — but it became the basis for Go modules, which arrived as a preview in Go 1.11 (2018), gained the proxy and checksum database in Go 1.13 (2019), and became the default in Go 1.16 (2021). The go.mod / go.sum pair, the public module proxy at proxy.golang.org, and the checksum database at sum.golang.org together ended the GOPATH era and made reproducible, verifiable builds the default.
Generics, at last (1.18, 2022)
Generics were the longest-running open question in Go's design. From the language's earliest days, the absence of parametric polymorphism was the most-cited complaint — and for just as long the team resisted, unwilling to add a feature that compromised readability or compile speed. The breakthrough was the type-parameters design: functions and types can declare type parameters, and those parameters are constrained by interfaces that describe the operations the code needs (including a new ability for an interface to list concrete types as a constraint set). After more than a decade of proposals and rejected designs, generics shipped in Go 1.18 in March 2022 — the largest change to the language since Go 1 — and the standard library began growing generic helpers (slices, maps, cmp) in Go 1.21.
The six-month cadence and toolchain management
Since the Go 1.x line settled, Go has shipped two major releases a year — one in February and one in August — a predictable rhythm that tells you exactly when to expect the next version. Each release is supported until two newer majors exist, so security and bug fixes flow to the two latest lines. The cadence is deliberately boring, and that is the point.
Go 1.21 (2023) added forward and backward toolchain compatibility, which changed how versions are managed in practice. The go line in a go.mod now declares the minimum language version a module requires, a recorded GODEBUG history preserves old default behaviors so an upgrade doesn't silently change semantics, and the toolchain can automatically download and switch to the version a project asks for. The upshot: a repository pins the Go version it expects, and the local go command honors it without anyone juggling installs by hand.
Go on WebAssembly and WASI
Go's WebAssembly story started in Go 1.11 (2018) with the experimental js/wasm port, which compiles Go to run inside a browser's JavaScript host. That covers front-end and browser-embedded use, but it ties the binary to a JavaScript environment. The second chapter is the WASI port: Go 1.21 (2023) added wasip1 support for the WebAssembly System Interface, letting Go programs run in standalone server-side Wasm runtimes (Wasmtime, Wasmer, and friends) with access to a sandboxed system interface rather than a browser. Together they let one language target both the browser and the emerging server-side Wasm platform.
Is there a Go 2?
For a while the team talked about “Go 2” as a banner for the bigger changes under consideration — generics, a possible new error-handling syntax, and other experiments. In the end that thinking was folded back into the Go 1 line and delivered incrementally: generics landed in 1.18, error wrapping in 1.13, and the various error-handling syntax proposals were debated and ultimately set aside rather than shipped as a breaking release. The practical answer is simple. There are no Go 2 releases. The version numbers keep climbing inside the Go 1 series — 1.24, 1.25, 1.26 — and the Go 1 compatibility promise still holds. Whatever “Go 2” once meant has arrived a feature at a time, without ever breaking the contract from 2012.
Sources:
go.dev/doc/devel/release (the canonical release list);
the per-release notes at go.dev/doc (go1.N);
the Go 1 compatibility document;
the Go blog;
and the download archive at go.dev/dl. Current as of June 2026.
Mungomash LLC · More software pages