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`?
Java, XQuartz and the CLT separate header package aren't required for
everyone's Homebrew usage or a default macOS development install.
As a result, only show then in `brew config` when they are actually
installed.
Use the environment variables set by `brew test-bot`. Eventually we'll
disable Travis CI running CodeCov so move `TRAVIS` references to
`HOMEBREW_TRAVIS_CI` so it doesn't need whitelisted.
Also, fix `azure-pipelines.yml` so it's testing the correct version of
Homebrew/brew (the one checked out in the `pwd`).
Adjust the rules based on the current codebase. Remove various enable,
disables and default values that are unnecessary. Add more comments
explaining why. Make minor changes needed to enable a few more rules.
Use 124 max line length everywhere. Also, reduce tap max line length to
189 as Homebrew/homebrew-core has that as a maximum now. In future
Homebrew/homebrew-core will also be reduced to 124 maximum line length.
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
1. Running `brew linkage some_package` does not set the cache.
2. Running `brew linkage --cached some_package` when `DatabaseCache.empty?` returns `true` should build the cache.
3. Running `brew linkage --cached some_package` when `DatabaseCache.empty?` returns `false` should use the cache.
