end support for macOS 10.13 and 10.14 in Go 1.21

[heschi]

After internal discussion, we believe this summer will be a good time to drop support for macOS 10.13 and 10.14. 10.13 was last patched in Nov 2020 and 10.14 in Feb 2021.

On behalf of @golang/release, I propose we announce the end of support in the 1.20 release notes, and disable the builder for 1.21.

cc @golang/darwin

[glycerine]

On Fri, Feb 3, 2023 at 9:42 AM J. Aten wrote in golang-nuts:

Primarily the argument is that High Sierra is the most stable version of OSX,
and thus preferred by those who highly value stability and reliability. It is also the only
version supported on older hardware, such as my 2015 mac book pro. These mac books
have superior keyboards and better access to USB ports and HDMI ports. They are readily available on
the used market for testing purposes. Just last week I bought my wife one for only $320.
There are tens if not hundreds of listings on ebay.

Ian Lance Taylor replied:

Thanks. Required for older hardware seems like a valid reason to me.

Please comment on https://go.dev/issue/57125, which is the proposal
for dropping High Sierra support.

Ian

Dear Go maintainers,
I would prefer it if High Sierra (OSX 10.13.6) support were kept, as this is the last available version of OSX to run on older hardware, such as my 2015 mac book pro. Thank you.

[dmitshur]

It is also the only version supported on older hardware, such as my 2015 mac book pro.

@glycerine Is there a typo in that example? 2015 MacBook Pro models can run up to macOS 12 Monterey (released in 2021), see https://support.apple.com/en-us/HT212551.

[eliben]

Dear Go maintainers, I would prefer it if High Sierra (OSX 10.13.6) support were kept, as this is the last available version of OSX to run on older hardware, such as my 2015 mac book pro. Thank you.

I understand the sentiment, but supporting additional versions incurs cost both in work time for our team and in running additional HW for the builders. We have to draw the line somewhere for old releases, and drawing the line where the OS vendor itself stopped support seems entirely reasonable.

Ian's comment on the go-nuts thread summarizes our position well:

Our position is that it is actually Apple that is driving the upgrade
cycle you mention, not us. Apple chose to drop support for High
Sierra back in 2020, so anybody running a High Sierra system connected
to the Internet is at risk. Should we invest our limited resources on
supporting releases that even Apple has declined to support? If Apple
continued to support High Sierra, so would we.

[changkun]

If Go 1.20 supports High Sierra, will it be problematic for High Sierra users to use Go 1.20 other than Go 1.21 or any other sucessors?

[mikeschinkel]

I too would like to see support for High Sierra continue. Here is some additional information to support the hardware argument.

Currently on eBay there are over 300 Mac Minis from mid 2010 and mid 2011 and a quick eyeball makes it seem like they can be had for less than US$100. (And that doesn't count MacBooks or iMacs.) Older Mac Minis are an excellent machine for someone who can't afford to buy a new Mac and needs to set up as a home server for macOS-related work.

There are numerous videos on YouTube about using 2010 and 2011 Mac Minis (and even more about using mid 2012):

1. https://youtu.be/gTqlVdSfGK0
2. https://youtu.be/iqn2xGt3sos
3. https://youtu.be/9yFewmhDymc

Anyway, if GoLang stops supporting this hardware then these would no longer viable for testing and/or running newer Go code on macOS, albeit an earlier O/S version.

I know that a lot has to be taken into consideration but I wanted to add more details about how much hardware like this is available and what people might be using it for. #fwiw

[rsc]

The existence of old hardware is not sufficient to justify investing time into keeping Go running on these old systems. If Apple is no longer issuing security updates and fixes for the OS, then it doesn't make sense for Go to keep trying to support it either. We have limited developer bandwidth, and keeping Go working on current macOS is difficult enough. People trying to keep old Mac hardware running will be able to continue to run the older Go distributions.

More generally, the criteria are documented at https://github.com/golang/go/wiki/PortingPolicy#removing-old-operating-system-and-architecture-versions.

[rsc]

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

[beoran]

@rsc I think on the contrary that supporting old hardware is very important, but I can agree that supporting old Operating System is not. The solution seems to be to install Linux on this old hardware, it is perfectly possible to run a modern Linux on a 10 years old machine.

[artkiver]

The existence of old hardware is not sufficient to justify investing time into keeping Go running on these old systems. If Apple is no longer issuing security updates and fixes for the OS, then it doesn't make sense for Go to keep trying to support it either. We have limited developer bandwidth, and keeping Go working on current macOS is difficult enough. People trying to keep old Mac hardware running will be able to continue to run the older Go distributions.

More generally, the criteria are documented at https://github.com/golang/go/wiki/PortingPolicy#removing-old-operating-system-and-architecture-versions.

I came here via the travesty that is the "telemetry transparency" thread elsewhere.

This seems disingenuous at best, in checking MacPorts the go port (last updated approximate one week ago) port health reports that the CI/buildbots are reporting no errors going all the way back to OS X version Lion:
https://ports.macports.org/port/go/details/

While I acknowledge that Apple and Alphabet Inc./Google are for profit entities, given that libre/free open source projects such as OpenBSD support even older hardware (e.g. PPC from Apple) with relative aplomb and have far fewer developer resources or funding (OpenBSD did not even meet their modest fundraising goal for 2022 and their 2023 goal is set at a mere $350,000 which arguably: is lower than the annual salary of some technocrats in this industry with far fewer accolades to show for it), I think that what you are really communicating with such sentiments is that you and your team don't want to expend the energy or resources.

It's not a matter of it can't be done. I've already been tasked by at least one past employer (The Museum of Art and Digital Entertainment) to recreate prior art older than any of the aforementioned hardware or OSes to help attorneys at Alphabet Inc./Google invalidate spurious patents, but to suggest that how I was treated in such regards was inequitable, would be an understatement. I was then, rather deeply misled about what my research would result in and not too happy when I eventually learned of the results.

If I were to put on my Sysadmin hat, I would suggest to @glycerine that making use of tools such as https://github.com/dortania/OpenCore-Legacy-Patcher/ may be of some use, having previously utilized similar tools such as https://github.com/dosdude1/macos-catalina-patcher/ to run more recent macOS releases on hardware considered officially unsupported by Apple. However, as a software preservationist and someone who has been tasked with software escrow by Fortune 7 types of litigators as well in my career history, who also maintains an extensive personal collection of hardware and software in a locked and insured storage unit which shares striking similarities with a TLA congruent with "No Such Agency" I acknowledge: there are times and places where running more recent hardware and software is not just improprietous, such hacks can be non functional for certain use cases.

In which instance, I would again suggest that MacPorts' port health for go is still indicative that even older OS X versions are apparently, still running go with sufficient aplomb going back to 2011 vintage OS X Lion.

I wonder, do you think future generations are going to simply consider older things abandonware? I was taught to use punch cards in my youth and have certainly supported hardware and software older than I am, but it seems as if the current professed leaders in our field are happier to deprecate their toolchains with increasing rapidity without much sound justification given their employer's present valuation at $1398.36B?

Seems, pretty scheisty to me. Don't you think you have enough resources to do better? Others with far fewer resources are already actively demonstrating their communities do.

(Hint: mpstats in MacPorts is not turned on by default, and is only installed via consent of users who at any time can port uninstall mpstats just as easily as they ran port install mpstats. Moreover, MacPorts dates back to DarwinPorts from 2002 and was co-founded by jkh who also co-founded FreeBSD among other things. Maybe take a lead from others who have demonstrated more than a shred of decency in this field instead of punching down against rationale discourse in that thread elsewhere?)

[heschi]

@artkiver this issue is to discuss ending support for macOS 10.13 and 10.14, not the telemetry proposal or the funding model of various projects. If the MacPorts maintainers have a problem they're welcome to file an issue. In the meantime, I'd appreciate it if the issue stayed on-topic. Thanks.

Ending support for an OS version doesn't mean that older versions will break. It just means that we aren't going to worry about them one way or another. I personally wouldn't want to run operating systems that don't receive security updates, but if someone does, and Go happens to work for them, that's great. At worst, users can stick with old Go versions.

Other than that I think @ianlancetaylor and @rsc have summarized our position: supporting older operating systems has a real cost to the team, both in money and time, and we can't pay that cost forever.

[rsc]

Based on the stated policy, this seems like a clear accept.

[rsc]

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

[rsc]

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

[gopherbot]

Change https://go.dev/cl/500239 mentions this issue: doc/go1.21: document macOS and Windows requirements