Skip to content
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

update prerelease check to allow standard release #19001

Merged
merged 2 commits into from
Dec 27, 2024

Conversation

daeho-ro
Copy link
Member

@daeho-ro daeho-ro commented Dec 25, 2024

When a formula or cask is written on the github_prerelease_allowlist.json, prerelease is allowed but interestingly it prohibits regular release. I think this should be also allowed too.

Here is an example.

utm@beta cask has a version 4.6.1 but utm is now 4.6.3. On my thought, beta branch should always have more up to date version than the normal branch and so it should be 4.6.3 not 4.6.1.


  • 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?

@bevanjkay
Copy link
Member

bevanjkay commented Dec 25, 2024

I think this can be dependent on the release ethos of the individual product. There are definitely cask, such as utm-beta where pre-release and standard releases should be allowed. But there are also cases where we want the allowlist audit to fail for a non-pre-release.

I'm not certain on the best way forward, if we can use a different keyword, or if we need a different allowlist. But I don't think adjusting the current methodology is the right way forward, we probably need to maintain the status quo and have a modified version of handling the alternative.

@daeho-ro
Copy link
Member Author

daeho-ro commented Dec 25, 2024

Version allow string all itself really should be all, I think. If it really depends on the pre-release only, then it can be somehow like pre or any other string. But this may break some formula or cask and so we can keep all and add another one to allow utm@beta case.

@daeho-ro
Copy link
Member Author

I have added a commit just for discussion and it will be squashed later or drop the PR. Any suggestions and opinions are welcome!

@bevanjkay
Copy link
Member

If I remember correctly the "all" relates to pinning the skip to a specific version number, not a pre-release type.

@carlocab
Copy link
Member

See also #18488

@daeho-ro
Copy link
Member Author

daeho-ro commented Dec 25, 2024

Let us consider the chrome as an example. There is no need to provide a stable release for the canary channel because it can be installed separately. In this case, of course, prerelease exceptions are not required. However, for some packages like utm, it cannot be installed stable and beta at the same time. So, I thought it is more reasonable to provide the latest version whatever it is pre-release or stable for the beta channel because we can install one channel only.

This is the reason why I have submitted this changes and want to introduce any again, thanks @carlocab for the previous discussion.

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.

Makes sense to me, thanks @daeho-ro! Also 👍🏻 to not modifying existing all behaviour.

@MikeMcQuaid MikeMcQuaid added this pull request to the merge queue Dec 27, 2024
Merged via the queue into Homebrew:master with commit 3102e42 Dec 27, 2024
28 checks passed
@daeho-ro daeho-ro deleted the prerelease-update branch December 27, 2024 09:20
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.

4 participants