Why Go’s release policy is better than LTS

Go’s release model rewards regular upgrades instead of long-lived LTS branches.

Go should stay on its current path: no LTS track, just a strict two-major support window that forces teams to upgrade on schedule. The evidence is already in the release history. As of 18 May 2026, Go 1.26.3 is the latest stable release, Go 1.26 and 1.25 are supported, and Go 1.24 is already end of life. That cadence is not an accident. It is the point.

First, Go’s cadence is the feature, not the bug

Go ships major releases about every six months, with minor patches in between. That rhythm keeps the language moving without turning every maintenance cycle into a migration crisis. The current record shows a clean pattern: 1.26.0 landed on 10 Feb 2026, 1.26.3 followed on 07 May 2026, and 1.25.0 arrived on 12 Aug 2025. This is what predictable progress looks like.

Compare that with ecosystems that promise long-term support as a default. LTS often becomes a shelter for delay. Teams park on an old major because it feels safe, then discover they have accumulated years of runtime drift, library incompatibility, and security debt. Go’s policy makes that trap harder to fall into. When the two newest majors are the only supported ones, upgrade planning becomes a normal engineering habit rather than a panic project.

Second, the support window is already enough for serious systems

Go’s support policy is blunt: the two most recent major releases get bug fixes and critical security fixes, and everything older is end of life. That is a strong bar, not a weak one. It means teams running production services are never more than one major behind the active line of development, and they are never waiting years for the next security response. For a language built for backend systems, microservices, APIs, and cloud-native tools, that matters more than a marketing label like LTS.

The release table proves the model works. Go 1.24, released on 11 Feb 2025, reached end of life on 10 Feb 2026. Go 1.23 followed the same pattern, ending on 12 Aug 2025 after 1.24.0 shipped. That gives each major roughly one year of support once the next two majors exist, which is enough time for teams with real release discipline. If a team cannot upgrade within that window, the problem is not the language policy. The problem is the team’s dependency management.

The counter-argument

The strongest case for LTS is operational comfort. Enterprises want fewer upgrades, fewer regressions, and a longer runway for validation. They also want to align language upgrades with broader platform changes, especially in regulated environments where every change triggers review. On paper, a long-lived branch looks safer because it reduces churn and lets teams keep shipping without touching the runtime every few months.

That argument is not naïve. Some organizations do have release processes so heavy that a six-month cadence feels expensive. And some product teams would rather spend time on features than on dependency work. LTS gives those teams a familiar story: freeze on a known-good version and move only when absolutely necessary.

But that comfort is false economy. Go’s model accepts a real limit: teams must budget for regular upgrades. In exchange, they get a healthier baseline, fewer unsupported installations, and a security posture that does not depend on one ancient branch staying alive forever. The versionlog data makes the tradeoff explicit. Once a release falls outside the two newest majors, it gets no further updates at all. That is harsh, and it is exactly why it works. It prevents the ecosystem from filling up with forgotten versions that still compile but no longer deserve trust.

What to do with this

If you are an engineer, stop treating Go upgrades as optional cleanup. Track the current supported majors, test against the next release before your current one nears EOL, and make version checks part of CI. If you are a PM or founder, plan one upgrade window per year for Go-based services and treat it like any other reliability task. The right goal is not to avoid change. The right goal is to stay close enough to the release line that security, compatibility, and performance improvements reach production before support disappears.