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.) |
rsc
changed the title
|
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. |
rsc
changed the title
|
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 <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Auto-Submit: Dmitri Shuralyov <[email protected]> Reviewed-by: Than McIntosh <[email protected]>
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 <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Auto-Submit: Dmitri Shuralyov <[email protected]> Reviewed-by: Cherry Mui <[email protected]>
|
Change https://go.dev/cl/564217 mentions this issue: |
|
Change https://go.dev/cl/564215 mentions this issue: |
dmitshur
added
the
FixPending
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 <[email protected]> Auto-Submit: Dmitri Shuralyov <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Than McIntosh <[email protected]>
For golang#64207. For golang#23011. Change-Id: I17ff221718aef03e9cda0ae4eb7b79896933553a Reviewed-on: https://go-review.googlesource.com/c/go/+/549655 LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Michael Pratt <[email protected]> Auto-Submit: Dmitri Shuralyov <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]>
For golang#64207. For golang#65614. Change-Id: Ia5365b4090060e0657c255341751d3e67691f836 Reviewed-on: https://go-review.googlesource.com/c/go/+/563856 Reviewed-by: Dmitri Shuralyov <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Auto-Submit: Dmitri Shuralyov <[email protected]> Reviewed-by: Than McIntosh <[email protected]>
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 <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Auto-Submit: Dmitri Shuralyov <[email protected]> Reviewed-by: Cherry Mui <[email protected]>
|
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 <[email protected]> Auto-Submit: Dmitri Shuralyov <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]>
|
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?). |
|
Change https://go.dev/cl/647015 mentions this issue: |
Darwin builders with macOS 10.15 are not needed now that Go 1.24.0 is out and Go 1.22 stopped being supported per release policy¹. Reallocate some of the freed up capacity between public and internal swarming instances, weighing them slightly based on typical demand. For golang/go#64207. ¹ https://go.dev/doc/devel/release#policy Change-Id: I670d79ba297aba2d12720ecf9779f7c4fac457bd Reviewed-on: https://go-review.googlesource.com/c/build/+/647015 Reviewed-by: Cherry Mui <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Michael Pratt <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Reviewed-by: Carlos Amedee <[email protected]> Auto-Submit: Dmitri Shuralyov <[email protected]>
|
Change https://go.dev/cl/652235 mentions this issue: |
Makemac already takes on increasing instance count when the current amount falls under the configured MinCount, and decreasing instance count down to zero when an image outright stops being used. Extend that to also cover the case of decreasing the instance count when the configured target Count is lower than the current, as done recently in CL 647015. Note that we could also have kept MinCount and added MaxCount, but that flexibility isn't needed now. It can be added if we ever want to set MinCount != MaxCount. For golang/go#64207. Change-Id: Ifdf898365dafe70cf33be37ec51d80290c625eb5 Reviewed-on: https://go-review.googlesource.com/c/build/+/652235 Reviewed-by: Dmitri Shuralyov <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Michael Pratt <[email protected]> Auto-Submit: Dmitri Shuralyov <[email protected]>
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: