Document our policy towards macOS support

[jbytheway]

Summary

Infrastructure "Document our policy towards macOS support"

Purpose of change

Discussion in #49595 has made it clear that we didn't really have a useful policy with respect to support for macOS and XCode.

This is a follow-up to #49598 which I'm opening separately because that PR is ready to merge and I don't want to confuse it with the separate discussion, whereas I want to offer an opportunity for other opinions on what support we should offer for macOS.

Our policy for other platforms / compilers is that we support those versions which still have official support from the distributor. macOS differs from our other platforms in that it's harder for our users and developers to upgrade, because the OS and hardware versions are linked. This leads to more people using unsupported versions. And indeed we have users and active developers using unsupported versions of macOS (see discussion in #49595).

Our practice in the past has been to mostly ignore the issue, just bumping the version when we ran into an issue on a particular version that upgrading seemed to help with. That isn't very satisfactory.

Describe the solution

We support Ubuntu LTS releases which last for five years. By analogy, I'm suggesting we support XCode releases for five years also. Currently we don't actually offer that much support, and I'm not proposing we attempt to backport to older versions now, but aspire to maintain five years of support when deciding to remove support for old versions.

Support for particular XCode versions can be translated into support for their corresponding macOS versions via this table of compatibility.

Note that XCode adopts new C++ features more slowly than any other major compiler, so this decision directly impacts when we will be able to take advantage of new C++ features. For example, I was hoping that after #49598 was merged we would be able to advance to C++17 immediately. However, if we accept this five year support guideline we will have to wait an additional two years until June 2023 to get even a reasonable subset of C++17 support in XCode 10.0.

Describe alternatives you've considered

Supporting only those macOS versions which Apple still supports would lead to roughly two to three years of support. Currently the oldest supported version is Mojave (10.14), which corresponds to XCode 10.2, released in March 2019. Older versions have something like a 10% market share currently.

Of course, we can pick any other arbitrary amount of time.

Testing

Not applicable.

Additional context

Ping @actual-nh, @BrettDong, @kevingranade.

[actual-nh]

It should be noted that the MacOS support in question is not only for developers, but for users, due to dynamic linking (static linking is not supported by the MacOS ld except for the kernel, at least according to the manpage).

[ralreegorganon]

Just as another data point, I do/did CDDA development on a mac and my Macbook Pro is ~8 years old (late 2013 model) and can support the latest released version (Big Sur, 11.x). It's totally anecdotal based on doing Mac development in other contexts but in general I've found that Mac users tend to fairly rapidly advance to the latest version of the OS that their hardware supports (and developers even more so). It seems a real shame to delay the advancement of C++17 support for so long.

[actual-nh]

Interesting. I have a mid-2011 Mac Mini, and it won't go beyond 10.12.6. Mine probably has a lower-end processor for the time; a Macbook Pro's minimum processor is likely above that.

EDIT: Yes; my wife's Macbook Pro is from late 2011, and its max is 10.13.6.

EDIT2: I personally MIGHT be able to get an adequate-version gcc (or non-Apple clang) running, but I'm still concerned about the 10% of users noted above.

[kevingranade]

If I'm reading that chart correctly, it's more like 15% in total, though I'm not familiar with the release names. That seems high, and the prospect of it significantly improving does not look great either, Mojave+ only went from 72% market share to 82% over the last year.

I'm not sure a duration is a reasonable thing to commit to, we're trading access to language features for availability for customers. I'd prefer to be explicit about a market share goal if that's our criteria.

When we make the flip, I think the criteria needs to be, "is the size/proportion of the excluded population acceptable?", so the real question is what the size of that excluded population is.

10% still feels high to me, 5% is definitely getting there. I don't think meaningfully sub-5% is realistic, the long tail of users is very long.

[jbytheway]

I wrote a script to reformat the data from gs.statcounter.com into something more useful for us. Here are the cumulative totals of users at or below each version number across the last few months:

2020-07 :: 10.11:  8.5  10.12: 13.7  10.13: 26.9  10.14: 44.6  10.15: 99.5  
2020-08 :: 10.11:  8.0  10.12: 12.9  10.13: 25.6  10.14: 42.0  10.15: 99.3  
2020-09 :: 10.11:  7.6  10.12: 12.4  10.13: 24.7  10.14: 40.3  10.15: 99.3  
2020-10 :: 10.11:  7.0  10.12: 11.5  10.13: 23.1  10.14: 37.5  10.15: 99.4  
2020-11 :: 10.11:  6.2  10.12:  9.9  10.13: 19.2  10.14: 31.6  10.15: 97.4  
2020-12 :: 10.11:  5.9  10.12:  9.4  10.13: 18.2  10.14: 29.9  10.15: 93.5  
2021-01 :: 10.11:  6.0  10.12:  9.3  10.13: 17.6  10.14: 28.2  10.15: 91.2  
2021-02 :: 10.11:  8.1  10.12: 11.3  10.13: 19.5  10.14: 29.2  10.15: 89.3  
2021-03 :: 10.11:  8.3  10.12: 11.4  10.13: 19.2  10.14: 28.6  10.15: 88.1  
2021-04 :: 10.11:  8.5  10.12: 11.4  10.13: 19.0  10.14: 28.1  10.15: 90.2  
2021-05 :: 10.11:  8.2  10.12: 11.0  10.13: 18.3  10.14: 27.0  10.15: 98.1  
2021-06 :: 10.11:  6.6  10.12:  9.3  10.13: 16.3  10.14: 24.6  10.15: 99.0  
2021-07 :: 10.11:  4.7  10.12:  7.4  10.13: 14.2  10.14: 22.1  10.15: 99.3  

So if we use a 5% threshold then as of July we can drop support for 10.11 (which we already did, so that's nice) and we might be able to drop support for 10.12 in a few months if the current trend continues (though there's obviously some drift up and down).

That seems reasonable. I'll re-jig this PR to something along those lines.

[jbytheway]

OK, rewritten and rebased. Marking ready for review.

[actual-nh]

It may be of interest that I have finally gotten around to doing some updates with MacPorts, and have discovered that - at least supposedly; I've not tried out the compilers and libraries in question - I now have LLVM 9-12 and LLVM clang 11-12, including libraries. More importantly, this does not solve anything for users, except indicate that referring them to Brew (or MacPorts; CDDA is not listed on MacPorts currently, however) may be something to help those with older MacOS versions. (Admittedly, the difficulties with 0.F for which Brew was a workaround do not appear to have made its use very acceptable to many.)

BTW, in what package to download, MacPorts is not going by OS version, judging from the filenames; it's going off of Darwin major kernel version (16 in my case) + microprocessor grouping (x86_64 in my case).

[jbytheway]

Quick update. I took another look at the usage statistics:

2021-05 :: 10.11:  8.2  10.12: 11.0  10.13: 18.3  10.14: 27.0  10.15: 98.1  
2021-06 :: 10.11:  6.6  10.12:  9.3  10.13: 16.3  10.14: 24.6  10.15: 99.0  
2021-07 :: 10.11:  4.6  10.12:  7.3  10.13: 14.2  10.14: 22.1  10.15: 99.3  
2021-08 :: 10.11:  4.5  10.12:  7.1  10.13: 13.9  10.14: 21.4  10.15: 99.2  
2021-09 :: 10.11:  4.2  10.12:  6.6  10.13: 13.7  10.14: 20.9  10.15: 99.2  
2021-10 :: 10.11:  3.8  10.12:  6.2  10.13: 12.2  10.14: 19.1  10.15: 99.1  

Looks like the relevant number continues to drop by ~0.4% per month, so in another 3-4 months we might be in a position to drop 10.12 support. So, I guess we might end up doing so after the next stable release.