DISCUSS: Raise MacOS minimum target from 10.13 to 11.0

[h-vetinari]

This issue follows in the footsteps of #1844, because apple obviously keeps releasing new macOS versions every year, and the length of the official support hasn't changed, so no matter the length of the chosen support windows, versions "fall off" once a year (officially apple dropped support for 12.0 already).

We actually decided to move to 10.13 already in August 2023 (but #1844 took a long time to resolve because we first had to get #2102 in place, which itself took many months to pull off, culminating in conda-forge/conda-forge-pinning-feedstock#5829), so by the same standard (relative to the EOL of a given version; i.e. drop one for each passing year), we could already move on to 10.14 or even 10.15.

Of course, our decisions end up being driven by the requirements of key projects in the ecosystem, where it gets increasingly untenable to support older versions. At the time, protobuf and grpc were among the first to require 10.13, and eventually even libc++ itself (a key component of the C++ compiler stack) required it. Libc++ at the time moved on as soon as chrome (the last major holdout) had required 10.13 itself.

It looks like we'll replay the situation in some sense, because a lot of the google-affiliated projects are now setting the baseline using their "foundational C++ support policy" (here in matrix form). In particular, it says

We will support back to the oldest macOS target platform needed by Chrome

Chrome nowadays requires macOS 11.0, and so the matrix has also been updated. More concretely, grpc 1.69 bumped the requirement to 10.14 (grpc/grpc@14ac94d) and protobuf v30 requires 10.15 (protocolbuffers/protobuf@67fca5c) the upcoming grpc 1.72 will require 11.0 (grpc/grpc@f122d24).

In other words, the next grpc migration (likely for 1.71) will anyway already need to carry

c_stdlib_version:  # [osx and x86_64]
  - 10.14          # [osx and x86_64]

but this is annoying because then we can never close the migrator (see the situation how we kept around already done abseil/grpc migrators because we couldn't close them without raising the global minimum, c.f. conda-forge/conda-forge-pinning-feedstock#5852).

As such, we should start the discussion when we can move to 11.0 (or in the short term, at least 10.14).

In terms of usage numbers, I did an analysis based on PyPI downloads not too long ago (as always, it would be great if we could get such data from our own downloads instead of using a proxy), and the result was that 98% of users are on macOS >=11.0 and 99% >=10.14 (this was measured using requests downloads as a proxy because it's so widespread; over a period of 4 weeks in December; for a less generic library like pillow, it was 99.6% >=11.0).

[h-vetinari]

CC @conda-forge/core

[beckermr]

Following chrome while allowing for some delay on our end seems like a good solution.

[isuruf]

Following libcxx is fine, but following Chrome is not. (libc++ might depend on Chrome).
We really should figure out a way forward for making this bump not be global.

[h-vetinari]

libc++ might depend on Chrome

Can you explain what you mean here? Previously, libcxx dropped support for <10.13, because chrome was the last consumer of libcxx that had dropped <10.13.

We really should figure out a way forward for making this bump not be global.

I mean, if you're concerned about dropping support before we're really forced to (basically the leverage that only libcxx has), I think the "keep around migrator file" is an acceptable approach. At least, I don't really see a better non-global solution.

OTOH, I think it's equally tenable to have a policy of dropping macOS versions something like ~7 years after release (that would be dropping 10.13 in September 2024), especially when user numbers drop off precipitously for old versions.