dev-cmd/bump: add switch to open pull requests.

[MikeMcQuaid]

This enables the simplification of https://github.com/Homebrew/actions/blob/master/bump-formulae/main.rb and exposing this workflow to more Homebrew users.

CC @dawidd6 @samford @chenrui333 @carlocab for thoughts and feedback

[carlocab]

Very nice ❤️

[BrewTestBot]

Review period will end on 2022-01-12 at 15:04:51 UTC.

[chenrui333]

lgtm

[nandahkrishna]

🚀

[MikeMcQuaid]

Thanks @samford, updated now, let me know what you think!

[BrewTestBot]

Review period ended.

[samford]

One last thing I missed before and this should be good from my point of view.

[samford]

In testing this, I happened to choose a cask (1password) where Repology gives the latest Windows version (8.4.1) as newest but livecheck correctly gives the newest release for Mac (7.9.2, 8.x is still early access for Mac). In this scenario, brew bump would create a cask PR for an inappropriate version, which we don't want.

There may be something to be said for only creating a PR based on livecheck's data, as it tends to be contextually-appropriate with regard to a given formula/cask. livecheck's data isn't perfect (e.g., livecheck blocks sometimes break and need to be updated, homebrew/cask needs a lot of livecheck-related work, etc.) but it's in our power to address any problems that we encounter. Repology's data may or may not be correct with respect to a formula/cask and there's nothing we can do if the information isn't applicable.

It's nice to have Repology for comparison (e.g., so we know when we need to make livecheck changes) but I think we should limit it to that use case unless/until the benefits outweigh the potential detriments. If we go this route, it should be as simple as removing the Repology-related elsif branch where new_version is defined.

Alternatively, we could act on Repology's data only when livecheck doesn't provide any data, though the detriments may still outweigh any benefits. livecheck's data for homebrew/core is pretty good these days (only ~100 formulae are uncheckable but almost all of those should simply be skipped), so this would primarily apply to homebrew/cask. However, casks are intended for Macs but Repology collects data across platforms (Windows, Linux, etc.), so the newest version may not be appropriate for us. It's something we could consider once we've compared version data for existing formulae/casks and weighed benefits/detriments but I think it would still be better to only act on livecheck's data for now.

Thoughts on this?

[MikeMcQuaid]

@samford I can see the argument for not relying on Repology for homebrew/core. Even in that case, though, Repology indicates that there's a 2.0.0 version of wget that we don't detect. Do we want to automatically open a PR for that? Maybe not. Do we want to be notified of that? Probably?

If it'd make you feel better about merging this: I can see an argument to just create PRs based on livecheck for formulae and still allow creating cask PRs based on Repology until there's complaints about it not being useful. Alternatively, for casks and/or formula: we only create PRs using repology data if --repology is passed, or similar.

I don't think making both casks and formulae use only livecheck data indefinitely is appropriate. Yes, we have more control over livecheck data but having multiple sources and relying on another project who exists just to do this seems like a good longer-term decision.

Thoughts?

[samford]

At the moment, we can simply remove a formula/cask from autobump.yml when Repology's version is inappropriate (as with 1password), so my concerns aren't a blocker for this PR and I'm good with it being merged.

I'll work on a comprehensive comparison of livecheck and Repology versions in core/cask, so we have some concrete data on how beneficial/detrimental opening PRs based on Repology versions will be in practice. Once that's done, I'll try to open an issue (or a PR?) where we can further discuss related issues and how we could approach them.

Thanks, @MikeMcQuaid!

[MikeMcQuaid]

Thanks @samford, much appreciated. We should continue to monitor user PRs submitted due to this and see if they end up being worth tweaking the settings for. Appreciate your thoughtful testing, review and feedback here, you rock ❤️