proposal: all: end support for macOS 12 in Go 1.27

[prattmic]

Proposal Details

The last security update macOS 12 received was in July 2024. I believe the summer of 2026 will be a good time to drop support for macOS 12.

On behalf of @golang/release, I propose we announce the end of support in the Go 1.26 release notes, and disable the builder for Go 1.27. Go 1.26 (security patches until Feb 2027) will be the last release with macOS 12 support.

For context, #64207 (comment) contains some history as well as future patterns if we keep the same cadence.

https://telemetry.go.dev/#charts%3acmd%2fgo%3ago%2fplatform%2fhost%2fdarwin%2fmajor-version shows the frequency of darwin kernel versions among cmd/go users that opt-in to telemetry. Darwin kernel version 21 corresponds to macOS 12. As of 2025-10-09, ~0.8% of reports are on macOS 12.

CC @golang/darwin.

[gabyhelp]

Related Issues

• all: end support for macOS 11 in Go 1.25 #69839 (closed)
• all: end support for macOS 10.15 in Go 1.23 #64207 (closed)
• end support for macOS 10.13 and 10.14 in Go 1.21 #57125 (closed)
• all: announce end of support for old macOS releases #23011
• x/build/cmd/release: confirm selection of darwin/arm64 releaselet macOS version for next minor release #49889 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[mbsulliv]

I'm a bit late to the "dropping old OS support" discussions, but better late than never...

I was surprised to see this proposal because my expectation for ending support for an OS version is that Go CAN'T work due to an OS incompatibility (e.g. a required syscall is missing). I encountered this in Linux where I tried to run a Go program on RHEL 5 and it died when trying to use the missing syscall. That's when I discovered that Go had a minimum Linux kernel version requirement, but in the case of MacOS 12, there is no technical reason to drop support.

In the interests of trying to understand the impacts of this, I reviewed the minimum supported versions page. At first I was hopeful that I could just run with older Go tooling on older OSes, but I think I'd hit a wall if I happened to pull in a dependency that required a newer version of Go than what is supported.

I would like to propose that, instead of just systematically dropping support when the vendor stops updating an OS, you wait until there is a technical reason why the burden of continuing support is no longer worth it. That way, Go programs are more likely to run on old systems that may still be in use.

[prattmic]

I'm not sure where we have written it down, but in general "end support" in these proposals means that we stop testing on that version and no longer guarantee that it will work (i.e., we likely won't fix bugs that affect only that version).

We don't necessarily go out of our way to intentionally break those versions, unless there are features only present in newer OS versions that we have been waiting to use.

For example, looking through the CLs on #69839, we did not submit any CLs that intentionally break things on macOS 11. It's quite possible that Go 1.25 binaries continue to work fine on macOS 11.

[mbsulliv]

I guess I can take some consolation in that :)

[aclements]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— aclements for the proposal review group