- Use default `custom-prefix` label on macOS ARM (as `/usr/local` is
not the default).
- Add architecture (or Rosetta) to analytics event label.
- Don't send minor versions on Big Sur.
- Remove defunct `HOMEBREW_OSX_VERSION` reference.
Companion to https://github.com/Homebrew/brew/pull/7698.
Provide better, `odeprecated` messaging for
`depends_on :macos => :mavericks` and otherwise just fix up the code
that relied on `:mavericks`.
This is a developer-only feature, so it's gated via `HOMEBREW_DEVELOPER`.
This is intended to enable testing of macOS 10.15; users building software
manually to test compatibility of early betas need to be able to build
software from source instead of via pouring 10.14 bottles. This isn't
intended to be a general-purpose `HOMEBREW_BUILD_FROM_SOURCE` replacement,
and has no effect on released versions of macOS.
When Mojave was in beta we made it so that High Sierra bottles would
automatically be used on Mojave. Let's make this the default in general:
older bottles will be used on newer versions of macOS when a newer
bottle is not available.
This should make it easier for taps to bottle single versions of bottles
which will work more widely and to give us breathing room whenever a new
version of macOS is released.
Currently this only applies to the `wine` formula which will have the
`or_later` removed in a Homebrew/homebrew-core PR.
Question: should we use an `odeprecated` for the use of `or_later`?
Rather than relying on a `HOMEBREW_FORCE_BOTTLE` variable (which ends
up doing silly things like forcing bottle usage even when options are
provided) instead handle this at the `or_later` bottle detection
level so on prerelease versions of macOS any bottle looks like an
`or_later` bottle (unless various environment variables are set).
Fixes issues noted in:
https://github.com/Homebrew/brew/pull/4520#issuecomment-407229605
When reproducing issues with software that hasn’t been bottled yet on
your version of macOS it can sometimes be helpful to use `or_later`
bottle functionality i.e. just use the bottle for the latest version of
macOS available. This maps well to the existing `--force-bottle`
argument so it will now act as if the latest bottle has a `or_later`
ending.
It's more useful to be able to "bless" an existing bottle to be used on
later OSs (e.g. where it cannot yet be built) than it is to have to
create a new, identical bottle just to have a different filename.
