Proposal: consider dropping support for macOS 10.15 & macOS 11

[huonw]

Is your feature request related to a problem? Please describe.

Our releases currently support machines running old versions of macOS:

• macOS 10.15 or newer, on x86-64
• macOS 11 or newer, on arm64

To support these, we use dedicated physical machines, hosted in MacStadium. These self-hosted runners have a few downsides:

• cost: the Pantsbuild project pays for them directly
• fragility: they semi-regularly stop running jobs and require rebooting, and occasionally have their disk filled.
• limited resources: there's only a single instance, so they cannot sensibly by used for running tests on every PR (Run tests on MacOS ARM in CI #20993)

There's also a theoretical downside where we have to do backflips to support the older platforms (e.g. work around bugs that are fixed in newer versions). I haven't personally observed this for Pants yet, but it's theoretically possible, and maybe someone else has!

According to the GitHub Actions docs the supported macOS runners are versions 12 & 13 on x86-64, and 14 on arm64.

It seems that Apple only supports version 12 and newer, not 10.15 or 11.

Expand for details on macOS versions

macOS has apparently had https://en.wikipedia.org/wiki/MacOS_version_history#Releases this release schedule:

version	first released	last update
10.15	Oct 2019	Jul 2022
11	Nov 2020	Sep 2023
12	Oct 2021	May 2024
13	Oct 2022	May 2024
14	Sep 2023	May 2024
15	just announced, not yet released	-

This suggests that 12+ are supported by Apple and 10.15 and 11 are not.

Expand for details on hardware support

x86-64

Using Github-hosted runners would require moving from 10.15 to 12. The supported platforms seem to be:

• https://en.wikipedia.org/wiki/MacOS_Catalina#System_requirements
• https://en.wikipedia.org/wiki/MacOS_Monterey#Supported_hardware

Machine	Supported in 10.15	Supported in 12	More restrictive?
iMac	Late 2012 or later	Late 2015	yes
iMac Pro	2017	2017
MacBook	Early 2015 or later	Early 2016 or later	yes
MacBook Air	Mid 2012 or later	Early 2015 or later	yes
MacBook Pro	Mid 2012 or later	Early 2015 or later	yes
Mac Mini	Late 2012 or later	Late 2014 or later	yes
Mac Pro	Late 2013 or latre	Late 2013 or before
Mac Studio	-	2022

We'd be losing support for this hardware:

• iMacs, MacBook Airs, MacBook Pros before 2015
• Macbooks before 2016
• Mac Mini before 2014

We'd also break people who haven't upgraded to macOS 12 or newer.

Arm64

Using Github-hosted runners would require moving from 11 to 14. It seems that macOS-14 supports all arm64 machines:

• 11: https://support.apple.com/en-au/103111
• 14: htps://support.apple.com/en-us/105113

In particular, all of these M1 items from the 11 list, also appear in the 14 list:

• MacBook Pro (13-inch, M1, 2020)
• MacBook Air (M1, 2020)
• iMac (24-inch, M1, 2021)
• Mac mini (M1, 2020)

So, we won't break hardware, except if someone hasn't upgraded to macOS 14.

Describe the solution you'd like

• Add code to pants that detects when it is running on an older platform with a deprecation message, that specifically includes a request for feedback if people need that support
• After that has been released for a version or two, just start building on the newer versions (12 for x86-64, 14 for arm64), dropping support for the older ones.

If we did this, we'd lose support for this hardware:

• iMacs, MacBook Airs, MacBook Pros before 2015
• Macbooks before 2016
• Mac Mini before 2014

(NB. this is all x86-65. We don't lose support for any arm64 hardware.)

We'd also break people who haven't upgraded to macOS 12 or newer on x86-64, or macOS 14 or newer on arm64.

Describe alternatives you've considered

1. Make macOS 12 the minimum supported version for both x86-64 and arm64. This means we could drop the self-hosted x86-64 runner, but would retain the arm64 one for now.
2. Continue supporting old platforms ~forever => seems untenable, as we'll be spending effort and energy supporting a decreasing number of users, potentially zero!
3. Just do a hard break: versions 10.15 and 11 are not supported by apple, so we could potentially break support for them right now => seems a bit unnecessary as we have a set-up that works tolerably well, and can continue with it for a while

Additional context

Background about why we use these self-hosted runners:

It’s about compatibility (with client’s version of Mac OS) and stability (runner availability). Now that GH offers Mac OS ARM runners, it may be time to consider dropping support for older Mac OS versions, if we find the runners reliable enough.

Related issues:

• Run tests on MacOS ARM in CI #20993
• Proposal: run the full test suite on all platforms, more often #20193

[huonw]

Before we commit to this, we may also want to confirm the reliability/performance/etc of the GitHub-hosted runners: maybe they have major problems and self-hosted one is significantly better?

[huonw]

Given GitHub is deprecating its macOS 12 runners (https://github.blog/changelog/2024-08-19-notice-of-upcoming-deprecations-and-breaking-changes-in-github-actions-runners/), I briefly investigated whether we could just jump to 13+ (https://en.wikipedia.org/wiki/MacOS_Ventura#Supported_hardware, https://support.apple.com/en-us/102861):

macOS Ventura supports Macs with Apple silicon and Intel's Xeon-W and 7th-generation Kaby Lake chips or later, and drops support for Macs released from 2015 to 2016, officially marking the end of support for the Retina MacBook Pro, 2015-2017 MacBook Air, 2014 Mac Mini, 2015 iMac and cylindrical Mac Pro. The 21.5 inch 2017 iMac is the only supported standard configuration model to have no retina display.

Machine	Supported in 10.15	Supported in 12	More restrictive?	Supported in 13	13 more restrictive than 12?
iMac	Late 2012 or later	Late 2015	yes	2017 or later	yes
iMac Pro	2017	2017		2017
MacBook	Early 2015 or later	Early 2016 or later	yes	2017 or later	yes
MacBook Air	Mid 2012 or later	Early 2015 or later	yes	2018 or later	yes
MacBook Pro	Mid 2012 or later	Early 2015 or later	yes	2017 or later	yes
Mac Mini	Late 2012 or later	Late 2014 or later	yes	2018 or later	yes
Mac Pro	Late 2013 or later	Late 2013 or before		2019 or later	yes
Mac Studio	-	2022		2022 or later

This seems like a significant jump, so worth doing macOS 12 alone if we can.

[sureshjoshi]

Deprecation of stuff in the Apple ecosystem is such a pain in general. Mostly because I do a lot of iOS development and Apple doesn't like to backport new functionality.

Anyways, when it comes to dev tooling on Mac (and other platforms to varying degrees), my policy tends to be: If Apple no longer releases security patches, then I'm less likely to support the system.

I'm not a fan of a hard break, unless it'll really speed up the code or remove a ton of cruft - so more of a deprecation and "we haven't tested it in CI, but it 'should' work"

Apple has their own terminology for HW deprecation (it's a bit more nuanced than this, but it's a good guide): https://support.apple.com/en-us/102772

Products are considered vintage when Apple stopped distributing them for sale more than 5 and less than 7 years ago.

Products are considered obsolete when Apple stopped distributing them for sale more than 7 years ago.

OS deprecation isn't 1:1 with this list, but it's usually a pretty good indicator of batches of machines that will be deprecated together. Though, it's worth noting that commonly "obsoleted" or "vintage" Mac hardware end up as CI systems 🤷🏽

Overall, unless there is a specific dependency issue (which can crop up given the number of deps we use), my vote is for deprecation via "It's not tested in CI anymore, your mileage may vary" and then handle bugs on old OSes on a case-by-case (and honestly, unless it's a security bug, I wouldn't handle it).