This is a naive attempt at creating an RBI compiler for the
`Cask::Config` class. `Config` contains methods like `appdir` that
are defined dynamically using the class's default values and Sorbet
doesn't understand that these methods exist or what their return
types are. This compiler works as expected and gets the job done but
I know basically nothing about Tapioca, so there may be a better way
of doing this.
For what it's worth, this isn't an issue right now but Sorbet will
surface an error once `Cask::DSL` is updated to `typed: strict` (i.e.,
`Method appdir does not exist on Cask::Config`). That's something
I've been working on and this compiler is intended as a way of
preemptively resolving that Sorbet error, so I can move forward with
the `Cask::DSL` type signature work.
This is the pattern we've been adopting for a while and it's a bit
cleaner. Let's remove all of the existing usage of the existing pattern
to avoid confusion when adopting the new one.
We have a `HOMEBREW_MACOS_NEWEST_UNSUPPORTED` environment variable
and this is used in `MacOSVersion` to determine prerelease versions
but we don't have a way of easily determining the newest supported
macOS version.
`bump-cask-pr` contains logic that assumes the first key/value in
`MacOSVersion::SYMBOLS` is the newest macOS version but it recently
became clear that this is a prerelease version between WWDC and the
subsequent macOS release. Similarly, `dev-cmd/generate-cask-api.rb`
tries to compute the newest stable macOS version as
`HOMEBREW_MACOS_NEWEST_UNSUPPORTED.to_i - 1` and this will fail
if/when we update that variable to `"26"`, as the macOS version
before 26 is 15, not 25.
This adds a `HOMEBREW_MACOS_NEWEST_SUPPORTED` environment variable,
so we have a straightforward way of quickly identifying the newest
supported macOS version without having to make potentially unreliable
assumptions or do computations to identify the latest non-prerelease
`MacOSVersion` value. This also updates the two aforementioned areas
to use this environment variable to produce the newest stable macOS
version symbol in a more reliable way.
I noticed recently the SBOM workflow was failing and had been for a long
time and we'd not noticed. I've added issues for the other workflows
that run on a schedule and fixed the updating state.
I've also renamed the SBOM workflow to `sbom.yml` to match what it does.
Co-authored-by: Rylan Polster <rslpolster@gmail.com>
