Bump minimum OS to Yosemite

[mistydemeo]

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes? Here's an example.
• Have you successfully run brew style with your changes locally?
• Have you successfully run brew tests with your changes locally?

---

This bumps the minimum OS version from Mavericks to Yosemite. Mavericks was already officially on life support, and wasn't receiving official support.

This is in support of #7675, Vidushee's Sorbet branch. Sorbet is very slow and error-prone to build, so it's not practical to install except using binary packages. They provide binary packages going back to Darwin 14 - e.g., macOS 10.10. In order to install that, we'll need our vendored Ruby to be built for at least that macOS version. Right now, since Homebrew runs on macOS going back to 10.9, we build our vendored Ruby for that version and it's unable to use any of the Sorbet binary packages.

I've built a new portable Ruby 2.6.3 for Yosemite and uploaded it to Bintray. I'll publish it and push it to GitHub when this branch is approved.

[mistydemeo]

Aside: if Misty is the one raising the minimum OS version, you know there's got to be a good reason. 😆

[MikeMcQuaid]

Note to self: clean up all :mavericks references in Homebrew/brew and Homebrew/homebrew-core after this is merged.

[Bo98]

Looks good. Will existing users get the updated Portable Ruby however? We want to make sure they do.

One concern: this could mean that bumping the minimum OS becomes Sorbet's decision and not ours. If Sorbet suddenly drops 10.10-10.14 tomorrow say, are we fine with staying on the older version of Sorbet?

[Bo98]

Note to self: clean up all :mavericks references

If it is possible to deprecate in a way that depends_on :macos => :mavericks is still valid but with a deprecation warning, that might avoid some taps suddenly breaking without warning.

Might end up being a special case for depends_on. I think every other usage is okay to delete.

[Bo98]

Last question (sorry): we use system Ruby on Catalina, which is built for darwin-19 rather than portable Ruby's darwin-14. Does Sorbet's darwin-14 binaries work fine under a darwin-19 compiled Ruby? I notice that they provide multiple versions which makes me wonder that it doesn't work.

[mistydemeo]

If it is possible to deprecate in a way that depends_on :macos => :mavericks is still valid but with a deprecation warning, that might avoid some taps suddenly breaking without warning.

I think that'd be ideal, and give us a clean way to gradually clean things up on our end too.

Does Sorbet's darwin-14 binaries work fine under a darwin-19 compiled Ruby?

It does, but it won't be fetched in this context. I believe the reason they provide separate versions is to satisfy Rubygems, which fetches gems precisely matching RUBY_PLATFORM. It doesn't do an "or greater" type of fetching like we do, so Ruybgems won't, for example, fetch darwin-14 when running on darwin-19.

Rubygems should transparently fetch whichever is the appropriate version. That means it will work on Linux too.

Will existing users get the updated Portable Ruby however? We want to make sure they do.

They won't. At the current time this will only affect users running dev commands, most likely dev commands invoking Sorbet, but providing an upgrade mechanism would be useful.

One concern: this could mean that bumping the minimum OS becomes Sorbet's decision and not ours. If Sorbet suddenly drops 10.10-10.14 tomorrow say, are we fine with staying on the older version of Sorbet?

I think we can reevaluate if this becomes onerous. Right now I'm happy with this because their support schedule conveniently lines up with ours. If they suddenly drop all but the latest OS, that's obviously going to be a deal-breaker for us and we can make different decisions at that time.

[Bo98]

Rubygems should transparently fetch whichever is the appropriate version. That means it will work on Linux too.

Ok, cool. I asked because the darwin-14 version appears in the Gemfile.lock, or at least it did in the other pull request.

[issyl0]

Looks like the Ruby bump needs doing for Linuxbrew as well. 😩

Oh, it already is. Just seen the other PR. 😪

[MikeMcQuaid]

Note to self: clean up all :mavericks references in Homebrew/brew and Homebrew/homebrew-core after this is merged.

If it is possible to deprecate in a way that depends_on :macos => :mavericks is still valid but with a deprecation warning, that might avoid some taps suddenly breaking without warning.

Might end up being a special case for depends_on. I think every other usage is okay to delete.

Done in #7716

[MikeMcQuaid]

For release notes https://formulae.brew.sh/analytics/os-version/30d/ will be useful.

[MikeMcQuaid]

@mistydemeo once built from Homebrew/homebrew-portable-ruby#101 and it is merged: this is good to 🚢.

[mistydemeo]

Updated, and published the new rubies for Mac and Linux; I will be merging this once CI finishes.