bump-cask-pr: deprecate online flag

[razvanazamfirei]

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

---

This PR deprecates brew bump-cask-pr --online and makes online audits the default setting.

PRs created via bump-cask-pr skip full auditing. Occasionally, the bumped cask version does not match with the livecheck version leading to PRs that fail CI and clogging the PR queue until the livecheck version catches up.

Given that a --no-audit flag already exists, adding an --offline flag seems redundant. However, if there are any edge cases I'm missing, happy to discuss more.

[apainintheneck]

In general, this makes sense to me. Note that we usually try and wait for next major/minor release before changing deprecation status though. It might actually be nice to have a waiting to deprecate label for stuff like this.

• https://docs.brew.sh/Releases

[apainintheneck]

It'd be nice if we could customize the deprecation message some more. Something like --online is now on by default; use --no-audit to disable it would be helpful here. Not blocking though. It looks like deprecated would need to be modified in that case though. Or maybe something like:

if args.online?
  deprecated "brew bump-cask-pr --online"
  puts "`--online` is now the default. Use `--no-audit` to avoid online checks."
end

[MikeMcQuaid]

Comment this out for now and we'll add it on the next release.

[apainintheneck]

It's a bit tough though since there are other changes in the same file that need to be made in the same file. Probably better to just wait and do it all at once, right?

[MikeMcQuaid]

@apainintheneck I don't think these changes to a developer command need to wait until the next major/minor release. The odeprecated is more debatable and I'm fine either way. If we do want to add it: it'd be nicer to comment it out now otherwise it'll likely be bumped to odisabled on the next major/minor release which isn't what we want.

[razvanazamfirei]

@MikeMcQuaid I was not sure if we meant commenting out all the changes, or just odeprecated, so let me know if I need to revert any portion.

[MikeMcQuaid]

@razvanazamfirei Sorry for confusion: only the odeprecated line needs commented out.

[MikeMcQuaid]

Thanks again @razvanazamfirei!