formula_auditor: audit no_autobump! stanza on version bump

[botantony]

• 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 lgtm (style, typechecking and tests) with your changes locally?

---

• AI was used to generate or assist with generating this PR. Please specify below how you used AI to help you, and what steps you have taken to manually verify the changes.

---

I skipped cask auditor as there is no casks that use :requires_manual_review

[Copilot]

Pull request overview

This PR extends Homebrew’s auditing to flag misuse of the no_autobump! because: :requires_manual_review reason not only for new formulae/casks, but also when an existing formula’s version is bumped (using Git history to detect the version change).

Changes:

• Rename/expand the shared no_autobump audit helper to support both “new package” and “existing package on version bump” messaging.
• Update FormulaAuditor#audit_no_autobump to run an additional audit when the stable version differs from origin/HEAD.
• Adjust cask auditing and add/reshape formula auditor specs around the new behavior.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
Library/Homebrew/utils/shared_audits.rb	Generalizes the no_autobump audit message helper and changes the emitted warning text.
Library/Homebrew/formula_auditor.rb	Adds Git-based version-change detection to trigger no_autobump auditing on version bumps.
Library/Homebrew/cask/audit.rb	Switches to the new shared audit helper for new cask no_autobump validation.
Library/Homebrew/test/formula_auditor_spec.rb	Adds git-backed test setup and new cases for the version-bump no_autobump audit behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The warning text reads awkwardly ("temporary to-be deprecated reason"). Consider rephrasing to standard grammar (e.g., "temporary reason slated for deprecation") so the audit output is clear and consistent.

Suggested change

	"`:requires_manual_review` is a temporary to-be deprecated reason, #{msg}."
	"`:requires_manual_review` is a temporary reason slated for deprecation, #{msg}."

[MikeMcQuaid]

Can you add a #odeprecated somewhere to be uncommented when we're ready to deprecate for the next major/minor release?

[MikeMcQuaid]

@botantony Can you explain a bit more what this is doing any why? The PR description doesn't really provide any context. Thanks!

[MikeMcQuaid]

Can you add a #odeprecated somewhere to be uncommented when we're ready to deprecate for the next major/minor release?

[botantony]

@MikeMcQuaid right now there are a lot of formulae in core that use :requires_manual_review as an autobump exclusion reason. As it was intended to be a temporary reason, it would be good to remind the contributors to do a revision, and either add the package to the autobump list or use a more appropriate reason (f.e. :incompatible_version_format)

See https://machomebrew.slack.com/archives/C06G173B7/p1770641042793459, CC @SMillerDev

[MikeMcQuaid]

@botantony Sorry, I don't think it makes sense to push this work onto contributors. I wouldn't know based on the instructions from you above or in this PR what needs to be done and how I'd find out. Instead, I'd suggest either you do this work or create an issue to track progress and documentation so maintainers can do it.

[bevanjkay]

If we just need visibility on this, without causing CI to fail - what about triaging with a label? It's immediately obvious that a review could be beneficial, but is optional for the reviewer. I'm not sure too what extent labels just become noise?

[SMillerDev]

Maybe we can just have the style check remove this version of the no_autobump! stanza? That way it surfaces in PRs so maintainers can check it, and contributors don't need to do extra work.

[MikeMcQuaid]

Maybe we can just have the style check remove this version of the no_autobump! stanza? That way it surfaces in PRs so maintainers can check it, and contributors don't need to do extra work.

@SMillerDev how do we know if the autobump will work? I'm maybe missing something but I thought the point of the change was to deliberately have a human verify that these actually work?

[SMillerDev]

The build will fail if the autobump results differ from the actual version right? Or is that only for casks?