Skip to content

Add HOMEBREW_MACOS_NEWEST_SUPPORTED env var #20112

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 16, 2025

Conversation

samford
Copy link
Member

@samford samford commented Jun 14, 2025

  • 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 typecheck with your changes locally?
  • Have you successfully run brew tests with your changes locally?

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.

Partly related to discussion about not relying on MacOSVersion::SYMBOL order in #20108

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.
@samford samford force-pushed the add-newest-supported-env-var branch from 3d0091b to 764d2b2 Compare June 14, 2025 22:45
Copy link
Member

@MikeMcQuaid MikeMcQuaid left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great idea, thanks again @samford!

@MikeMcQuaid MikeMcQuaid added this pull request to the merge queue Jun 16, 2025
Merged via the queue into master with commit 62ca132 Jun 16, 2025
52 of 53 checks passed
@MikeMcQuaid MikeMcQuaid deleted the add-newest-supported-env-var branch June 16, 2025 07:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants