Go support policy turns releases into a checklist

I turn Go’s support table into a practical upgrade checklist you can copy.

I've been keeping Go fleets alive long enough to know the pain: the code compiles, the tests pass, and then someone asks which version is actually safe to ship. That’s where the usual developer confidence evaporates. I’ve seen teams pin a minor release, forget about it for a year, and then scramble when a security review asks whether they’re on a supported line. The annoying part is that Go itself is pretty disciplined here. The language doesn’t make the policy vague. The problem is us. We treat versioning like a background detail until it becomes a production question.

What finally helped me was treating the support schedule like a working document instead of trivia. I started reading endoflife.date’s Go page the same way I read a dependency lockfile: not for history, but for what I can safely keep running. That shift changed how I plan upgrades, how I talk to security folks, and how I decide when to roll a service forward instead of pretending the current version will be fine forever.

Stop asking “what’s latest” and ask “what’s still supported”

Each major Go release is supported until there are two newer major releases.

That one sentence is the whole game. Go doesn’t use a fuzzy “best effort” support model. It uses a simple sliding window: keep the current release and the two before it alive, and let the older ones age out when the next majors land. endoflife.date captures that policy directly on the Go product page, and it matches the official Go security policy.

What this actually means is that “latest” is not the same thing as “supported,” and “supported” is the only thing I care about when I’m responsible for production systems. I’ve been in shops where people proudly said, “We’re only one minor behind.” That sounds fine until you realize they’re one minor behind on a line that just fell out of support. Then you’re not being conservative. You’re being sloppy with a nicer adjective.

How to apply it: build your internal policy around supported majors, not release hype. If you run Go 1.24 and 1.26 is out, you’re already in the danger zone depending on the current window. Don’t wait for a security issue to force your hand. Put the support window in your engineering standards and make it visible in your deployment docs.

• Track the current supported major versions, not just the newest patch.
• Block new services from starting on unsupported majors.
• Set a calendar reminder for the next major release, not the next patch day.

Patch numbers are where the boring work lives

The page lists patch releases too, and that matters more than people admit. For example, Go 1.26.4 is shown as the latest for 1.26, and Go 1.25.11 is the latest for 1.25. Those patch numbers are the difference between “we’re on the right line” and “we’re on the right line with known bugs fixed.”

What this actually means is that support is not binary in the way teams like to pretend. A release line can still be maintained while individual patch levels drift. If you freeze on 1.25.0 because “we already upgraded to 1.25,” you’ve still left fixes on the table. That’s the kind of thing that feels harmless until a compiler bug or security fix lands in a later patch and you’re stuck explaining why you ignored it.

I ran into this when a service team wanted to standardize on a fresh major but refused to touch patch updates for the next quarter. Their argument was always the same: “We already did the hard part.” Sure, and then they spent more time debugging weird behavior than it would have taken to keep current. Patch discipline is cheaper than emergency debugging. Every time.

How to apply it: separate major upgrades from patch maintenance in your process. Major upgrades can be quarterly or semiannual. Patch updates should be routine. If you use CI, test against the latest patch in each supported line and make that the default build target.

• Maintain one “current supported” patch per active major.
• Update base images when patch releases land.
• Keep a short rollback path, but don’t use rollback as a substitute for patching.

The release table is a planning tool, not a museum label

endoflife.date shows a simple history: Go 1.26 is supported, 1.25 is supported, and 1.24 and earlier have ended. That’s not just archival data. It’s a planning surface. I use tables like this to answer three questions fast: what do we run now, what should we upgrade next, and what can we stop worrying about because it’s already dead.

What this actually means is that you can turn a static support table into a migration queue. If you know 1.24 ended when 1.26 arrived, then any service still pinned to 1.24 is no longer in the “maybe later” bucket. It’s in the “schedule it, or accept the risk” bucket. That’s a better conversation to have in a sprint review than in a postmortem.

I’ve found that teams waste time because they don’t distinguish between “unsupported but still working” and “safe enough to ignore.” Those are not the same thing. Unsupported software often works right up until the moment it doesn’t, and then the fix is no longer a routine patch. It becomes a forced upgrade under pressure, which is the worst time to learn your build scripts are brittle.

How to apply it: keep a small inventory of every Go runtime in your org. Tag each service with its current major version and support status. Then sort by risk, not by age alone. A low-traffic internal tool on an unsupported version still matters if it builds artifacts used elsewhere.

Go’s policy is simple, which is exactly why teams miss it

The Go project says supported releases get critical fixes, including critical security problems, as needed by issuing minor revisions. That’s the part teams should read twice. The project is telling you where the real maintenance line is: supported releases get fixes; unsupported ones don’t. That’s not a suggestion. That’s the operating model.

What this actually means is that your upgrade strategy should be built around support windows, not around how much your team enjoys changing dependencies. I wish that were obvious, but I keep seeing people make upgrade decisions based on convenience. “We’ll jump two majors later.” “We’ll wait until the next sprint.” “We only need it for one service.” That’s how you end up with a pile of exceptions that all look harmless until they’re not.

How to apply it: write one policy sentence and stick it in your engineering handbook. Mine is simple: no production deployment on an unsupported Go major unless there is an approved exception with an end date. That one line cuts through a lot of nonsense. It also gives security and platform teams something concrete to enforce.

If you need a reference point, the official docs are clear: the Go security policy explains how fixes are handled, and the Go release history gives you the release cadence context. I’d rather point people to those than argue from memory in a meeting.

Use endoflife.date as your quick sanity check

I like endoflife.date because it strips away the ceremony. It gives me the current release, the supported window, the latest patch, and the end dates without making me dig through changelogs. The Go page also links the product identifiers, the API, and the feed options, which makes it useful in automation as well as in browser tabs.

What this actually means is that I can use the page as a fast verification layer. When someone asks, “Are we safe on 1.25?” I don’t need to guess or search three docs. I can check the page, confirm whether 1.25 is still supported, and then decide whether the answer is “yes” or “yes, but update soon.” That distinction matters in real teams because it changes whether the ticket gets priority this week or next quarter.

I’ve also used the RSS and calendar feeds when I wanted release awareness without building my own reminder system. That’s not glamorous, but neither is getting surprised by a support cutoff. The point is to reduce surprises. The page is doing the boring part for you, which is exactly what a good reference should do.

How to apply it: use the page as a source of truth in team docs, then automate around it if you need to. If you manage multiple services, subscribe to the feed and wire the API into your inventory tooling. Don’t rely on memory, Slack folklore, or “I think we upgraded that last year.”

• Bookmark the Go page for quick checks during incident reviews.
• Use the API if you want version status in internal dashboards.
• Subscribe to the calendar or RSS feed if you own platform tooling.

Make the support window part of your release process

This is where I got more opinionated over time. I stopped treating Go upgrades as isolated chores and started treating them like release governance. If a service ships with Go, then the release process should already know which Go majors are allowed, which ones are nearing end-of-life, and which ones are banned outright.

What this actually means is that your build and release pipeline should reject drift before it becomes a problem. It’s a lot easier to prevent a new service from starting on an unsupported runtime than to drag a fleet forward after everyone has built assumptions around the old one. I’ve had to untangle that mess more than once, and it’s never pretty.

How to apply it: add a runtime check to CI, and make it fail on unsupported majors. Keep a short list of approved versions in a repo that platform engineers own. Then teach service owners to read the support table the same way they read a dependency advisory. If you’re already tracking CVEs, this is the same muscle, just aimed at release policy instead of package vulnerabilities.

One more thing: don’t confuse policy with panic. Go’s schedule is predictable enough that you can plan calmly. That’s the benefit here. You don’t need heroic upgrades. You need a habit. And once the habit is in place, the whole thing gets boring in the best possible way.

The template you can copy

# Go runtime support policy for internal services

## Allowed versions
- Production services must run on a supported Go major release.
- Supported means the current major release and the two prior major releases.
- Patch releases should stay current within the supported line.

## Required checks
- CI must fail if `go version` reports an unsupported major.
- New services must choose from the approved version list.
- Existing services must be reviewed when a major release enters or leaves support.

## Upgrade cadence
- Patch upgrades: monthly, or sooner for security fixes.
- Major upgrades: plan before the current version exits the support window.
- Exceptions: require an owner, a reason, and an end date.

## Operational checklist
1. Inventory every service and its Go version.
2. Compare each version against the current support table.
3. Prioritize services on unsupported majors.
4. Upgrade patch versions on supported lines.
5. Remove any exception before its end date.

## Reference sources
- Go support policy: https://go.dev/security/
- Release history: https://go.dev/doc/devel/release
- Support status page: https://endoflife.date/go

If you want this to be more than a doc nobody reads, wire the policy into CI and deployment gates. That’s the difference between a good rule and a decorative one. I’ve seen too many “standards” that only exist in a wiki. Those don’t help when a build is about to ship unsupported runtime code into production.

What I’m copying from endoflife.date here is the support framing, not the site’s wording. The table, the dates, and the release status come from endoflife.date/go; the policy interpretation and the workflow template are mine. If you need the canonical source for Go’s maintenance rules, start with go.dev/security and then use the support table to keep your team honest.