Go supports each major release until there are two newer major releases. During that time the project fixes critical problems, including critical security problems, in minor revisions such as 1.27.2. So at any moment two major versions are supported, and the older one drops off when the next major release ships.
The rule, in the project's words
The Go release history page states the policy: each major Go release is supported until there are two newer major releases. The page gives examples: Go 1.5 was supported until the Go 1.7 release, and Go 1.6 until Go 1.8. Critical problems, including critical security problems, are fixed in supported releases as needed, by issuing minor revisions.
Applying it today
When I checked on 19 October 2026, the page listed go1.27.0 (released 19 August 2026) and go1.26.0 (released 10 February 2026) as the newest majors. Go 1.27.2, released 8 October 2026, was described as including security fixes to the go command and to several standard library packages, as well as bug fixes. By the rule, Go 1.26 stays supported until Go 1.28 is released, and then it drops off. Anything older than 1.26 is already outside the stated support window.
| If you run | By the stated rule |
|---|---|
| The newest major | Supported |
| The previous major | Supported until the next major ships |
| Anything older | Unsupported, no new minor revisions promised |
Why this matters for your build
A Go program carries the standard library of the toolchain that built it. That means a fix in a minor revision reaches you only if you rebuild with the new toolchain. Updating a library in go.mod does not change the standard library inside your binary. This is why the toolchain version belongs in your inventory next to your module versions.
I am describing a general property of compiled programs here, not a quote from the policy page, so check how your own build pins its toolchain.
Steps
- Record the Go toolchain version used to build every service and tool.
- Compare it to the supported pair on the release history page.
- Rebuild and redeploy when a minor revision lists security fixes in packages you import.
- Make the toolchain version a visible setting in CI so a bump is a one line change.
- Keep an upgrade slot each half year for the move to the next major.
- For release artefacts you ship to customers, include the toolchain version in your SBOM.
For maintainers of Go libraries
Say in your README which Go versions you test. Following the same two release window is a simple default, and it keeps your support promise aligned with the toolchain's.
Try it yourself
Click through it at your own pace, or open it full screen. Notice that the inventory lists packages, then ask where your build toolchain would appear in a record like this.
Quick check
Does a newer library version fix a standard library bug?
Not by itself. The standard library comes from the toolchain used to build, so you need to rebuild with a fixed toolchain.
How many Go majors are supported?
Two at a time, by the project's rule.
Where do I see which minor revisions have security fixes?
On the Go release history page, which describes each revision.
How Safeguard helps
Safeguard can help you keep the support dates in view. Its SBOM and dependency scanning list the exact versions you run, reachability analysis shows which known issues your code can actually reach, and policies and gates can stop a build that pulls in a version you have decided to retire. Autonomous remediation can open fix pull requests; it is off by default and every category starts on Manual. You can try the free scan on a manifest first.
Sources
- The Go Project, Release History: release policy and recent minor revisions. Fetched 19 October 2026.
Last reviewed: 19 October 2026.
