codexmonitor 0.7.52 (new cask)

[lucasloisp]

Important: Do not tick a checkbox if you haven’t performed its action. Honesty is indispensable for a smooth review process.

In the following questions <cask> is the token of the cask you're submitting.

After making any changes to a cask, existing or new, verify:

• The submission is for a stable version or documented exception.
• brew audit --cask --online <cask> is error-free.
• brew style --fix <cask> reports no offenses.

Additionally, if adding a new cask:

• Named the cask according to the token reference.
• Checked the cask was not already refused (add your cask's name to the end of the search field).
• brew audit --cask --new <cask> worked successfully.
• HOMEBREW_NO_INSTALL_FROM_API=1 brew install --cask <cask> worked successfully.
• brew uninstall --cask <cask> worked successfully.

---

If AI was used to generate or assist with generating the PR:

• I used AI to generate or assist with generating this PR. Please specify below how you used AI to help you.
• I have personally reviewed, tested and verified all changes/additions, including zap stanza paths.

---

[p-linnane]

I'm concerned with how rapid the release cadence for this software is. @bevanjkay @samford I only see 2 examples of throttling in Homebrew/cask and neither is using DSL.

[bevanjkay]

Personally, I think it really only becomes a concern if the PRs become stale due to the release cadence - there's not as big overhead in homebrew-cask as homebrew-core. I think for standard use in homebrew-cask we need time-based throttling rather than version based, for it to be effective.

[lucasloisp]

Slightly agree with @p-linnane if I'm being honest. Release cadence for this software is ~daily, with some days having more than one release. Having a new PR opened daily to update the cask is potentially too much overheadw.

Potentially, could add throttling like in these other casks:

homebrew-cask/Casks/b/bettertouchtool@alpha.rb

Line 17 in a0adb05

# Throttle updates to every 5th release.

homebrew-cask/Casks/c/commander.rb

Line 11 in a0adb05

# a release for every version increase. This manually throttles versions to

Is time-based doable now? I presume not given what livecheck has access to it seems? If not then I suggest version-based, while not ideal, is sufficient.

[lucasloisp]

Just pushed a new change using the same throttling strategy as commander.rb! Should be sufficient for the use case I'd argue

[samford]

I recently merged a brew commit to add basic support for throttle handling to brew bump-cask-pr but it has the same limitations as the existing formula approach. Namely, it only throttles on the patch version and only works with versions that are divisible by the throttle rate. The current throttle-handling implementation doesn't work for the two casks that are throttled using a strategy block because one needs to throttle on version.csv.second and the other isn't compatible with the divisibility requirement (upstream doesn't create a release for every version number).

throttle should technically work for codexmonitor but upstream doesn't seem to be consistent with the release cadence (e.g., 0-3 releases per day). As we've acknowledged for some time, throttling based on time (e.g., one release per day) is generally what we're aiming for but the current throttle setup doesn't support it. [There's some recent internal discussion around this but it's something that will only happen when someone implements it and that's a bit of a challenge.]

That said, I think we have two options here:

• Preemptively use throttle 2 and accept that there may be days where the cadence is lower and throttling leads to no update PRs even though there's been a release. This uses auto_update true, so that means some users may see an update after installation and anyone who disables the in-app updater and uses brew upgrade --greedy will see slower updates through Homebrew. We could use a higher number but five may be too high (the cadence has been lower the past few days and seems to top out at three versions per day, whereas commander regularly exceeds five per day).
• Don't preemptively throttle the cask and see how the release cadence translates to autobump PRs. If the releases are spread throughout the day (with several hours in between), then autobump will produce multiple PRs. If some releases are close together (i.e., within the same autobump interval), then autobump will simply use the newest version at the time (skipping versions in between).

I'm fine with either option (the release cadence isn't as aggressive as commander) but I've added a simple livecheck block suggestion for the throttle approach, in case that's what we go with.

---

Besides that, 0.7.52 was released a few hours ago, so it would be good to update this.

[lucasloisp]

@samford terrific! Just updated to use throttle 2 -- and bumped to 0.7.52

[bevanjkay]

Thank you @lucasloisp 🚀