-
Notifications
You must be signed in to change notification settings - Fork 17.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
all: end support for macOS 10.15 in Go 1.23 #64207
Comments
Usually we link to our macOS history in these issues. Is #23011 (comment) the most recent statement of our history? Is there a better policy link? Regardless, since Apple stopped issuing updates in July 2022, and dropping in Go 1.23 would mean we stop issuing security patches (for Go 1.22) at the release of Go 1.24 in Feb 2025, that seems entirely reasonable. If anything we seem late. |
We had been following that pattern of adding a new macOS version and dropping the oldest one every 2 Go major releases (i.e., once a year) for a long while. After Go 1.17, there was a longer period where we supported older macOS versions, but Go 1.21 caught up by dropping two at once (proposal #57125). If this proposal is accepted, then:
And if we continue dropping oldest macOS once-every-two-major-Go-releases after that, the pattern would be:
|
It would be good to have a page somewhere indicating minimum OS versions currently required for the Go toolchain, and minimum OS versions supported by the Go runtime. (Apologies if there is one, but I haven't been able to find it.) |
https://github.com/golang/go/wiki/MinimumRequirements lists the minimum OS versions we require. |
Thanks. Do the minimum version requirements apply to the runtime for built binaries? |
@lpar I'm not sure what you are asking. They apply to everything in the built binary, runtime included. |
Thanks, that was what I was asking, whether ending support for macOS 10.15 meant that binaries compiled by the Go toolchain would no longer be supported on 10.15. (Binaries built with Go 1.21.x still seem to work on some unsupported macOS versions, but of course that doesn't mean it's supported that they do.) |
Based on the discussion above, this proposal seems like a likely accept. Following our usual pattern, more or less: Apple stopped issuing security updates for macOS 10.15 in July 2022. |
Shouldn't Go only drop support for older OS's if both:
Naively, it appears that the second case isn't true for this (or many of the previous drops). Other than keeping some builders alive, is there any real downside to allowing the latest Go toolchain to continue working on these older OS releases that we already have working? I'm asking because I like to stay with the current Go releases when developing, but this policy is going to force me to stop doing that, since a subset of my clients use OSs that are older than the officially supported versions out there. |
The problem is builders. If we support something, we need a builder for it. Running builders that aren't supported by the vendor is bad, because they are 1) connected to the internet, and 2) not receiving security patches. |
@randall77 it seems that security patches aren't the determining factor, as current versions of Go claim support for Linux kernels going all the way back to 2.6.32, which was EOL'd in March of 2016 (and versions of the 2.6.x line newer than that were EOL'd much earlier than that). |
See #60792 , there are ongoing discussions there about bumping the linux min version. RHEL 6 is still supported and runs a 2.6.32 kernel. https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux |
OK, fair enough. I didn't realize any Linux distributions were still supporting it (the few I checked were far beyond it). Anyway, definitely not happy about dropping support, but can understand it. |
You'd be surprised how much ongoing work it takes to keep all our builders running. Much of that work isn't visible as changes in the Go toolchain. Not running older, unsupported builders frees up time for higher priority work. |
No change in consensus, so accepted. 🎉 Following our usual pattern, more or less: Apple stopped issuing security updates for macOS 10.15 in July 2022. |
Change https://go.dev/cl/549655 mentions this issue: |
For #64207. For #23011. Change-Id: I17ff221718aef03e9cda0ae4eb7b79896933553a Reviewed-on: https://go-review.googlesource.com/c/go/+/549655 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This issue is currently labeled as early-in-cycle for Go 1.23. |
Change https://go.dev/cl/558197 mentions this issue: |
Go 1.23 will require macOS 11 Big Sur or later. For golang/go#64207. Change-Id: Ic628a771fbb22a8b05b3ff1b81e06d67c98f702b Reviewed-on: https://go-review.googlesource.com/c/build/+/558197 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org>
What's left to do for this issue (wearing my release interrupts hat) -- just something in the 1.23 release notes? Or do we need a change to the old (pre-LUCI) coordinator as well? |
Thanks for checking in. Here's a list showing the status of the remaining work here:
I've sent a release note CL just now, but the releasetargets package will be undergoing some bigger changes soon enough. I'll take care of it later on. All this needs to be done before Go 1.23 RC 1, but fine to ping if not finished by the release freeze. |
Change https://go.dev/cl/563856 mentions this issue: |
Is there a need to update this line in the linker https://cs.opensource.google/go/go/+/master:src/cmd/link/internal/ld/macho.go;l=486 ? Perhaps it is fine either way... Or we can wait until the old version causes some trouble. |
Thanks for pointing that out. The comment there says "This must be fairly recent" and "In general this can be the most recent supported macOS version." If I understand correctly, that means it shouldn't cause problems to set that version to macOS 14, the most recent macOS version now, and that there's no hard requirement for it to not fall below the minimum macOS version that Go supports. We didn't update it for when macOS 10.13 became unsupported. For now, I sent CL 563857 which seems like a small and safe step forward today. We can see if there's something more principled we should do for maintaining the version there later on. |
Change https://go.dev/cl/563857 mentions this issue: |
For #64207. For #65614. Change-Id: Ia5365b4090060e0657c255341751d3e67691f836 Reviewed-on: https://go-review.googlesource.com/c/go/+/563856 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
Go 1.23 will require macOS 11 Big Sur or later, even on AMD64. The comment here suggests the main requirement for the OS and SDK version is to be recent enough not to break Apple signing, and recent enough not to cause other problems. For now, this CL simplifies the code by merging the ARM64 and AMD64 cases into one, given 1.23 will be the first Go release with a common minimum macOS version for both architectures so there's no need to treat them separately here. For #64207. Change-Id: I821fcb9a2a316de0703833c8a75abcbaa10b17a3 Cq-Include-Trybots: luci.golang.try:gotip-darwin-amd64_11,gotip-darwin-amd64_14,gotip-darwin-arm64_11,gotip-darwin-arm64_13 Reviewed-on: https://go-review.googlesource.com/c/go/+/563857 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
Change https://go.dev/cl/564217 mentions this issue: |
Change https://go.dev/cl/564215 mentions this issue: |
CL 558197 updated LUCI builders to take into account that Go 1.23 will require macOS 11 Big Sur or later. We haven't fully migrated away from the old dashboard, so apply the same change here for now. For golang/go#64207. Change-Id: If0baa35d6f595d33911eaef43a467ad71c0a4c15 Reviewed-on: https://go-review.googlesource.com/c/build/+/564215 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Than McIntosh <thanm@google.com>
For golang#64207. For golang#23011. Change-Id: I17ff221718aef03e9cda0ae4eb7b79896933553a Reviewed-on: https://go-review.googlesource.com/c/go/+/549655 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
For golang#64207. For golang#65614. Change-Id: Ia5365b4090060e0657c255341751d3e67691f836 Reviewed-on: https://go-review.googlesource.com/c/go/+/563856 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
Go 1.23 will require macOS 11 Big Sur or later, even on AMD64. The comment here suggests the main requirement for the OS and SDK version is to be recent enough not to break Apple signing, and recent enough not to cause other problems. For now, this CL simplifies the code by merging the ARM64 and AMD64 cases into one, given 1.23 will be the first Go release with a common minimum macOS version for both architectures so there's no need to treat them separately here. For golang#64207. Change-Id: I821fcb9a2a316de0703833c8a75abcbaa10b17a3 Cq-Include-Trybots: luci.golang.try:gotip-darwin-amd64_11,gotip-darwin-amd64_14,gotip-darwin-arm64_11,gotip-darwin-arm64_13 Reviewed-on: https://go-review.googlesource.com/c/go/+/563857 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
Change https://go.dev/cl/605875 mentions this issue: |
Fixes golang/go#68891 For golang/go#64207 For golang/go#65614 Change-Id: I9256d9de0687b9e3cf674b4d318f4d5023a9bf16 Reviewed-on: https://go-review.googlesource.com/c/website/+/605875 Reviewed-by: Carlos Amedee <carlos@golang.org> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Hmm ... it is a shame though. I'm currently forced to use my old MacBook Pro from early 2013 which does not support macOS 11, which means that I need to stay on macOS 10.15 (unless I use something like https://dortania.github.io/OpenCore-Legacy-Patcher/). With this decision, it also means I can no longer use the latest Go if I understand this correctly (unless I can build from source?). |
Go added support for macOS 14 that was publicly released this September. After internal discussion, we believe the summer of 2024 will be a good time to drop support for macOS 10.15. The last security update it received was in July 2022.
On behalf of @golang/release, I propose we announce the end of support in the Go 1.22 release notes, and disable the builder for Go 1.23.
CC @golang/darwin.
The text was updated successfully, but these errors were encountered: