Process for moving a cask to versions on major version bump

[joshka]

Hiya,

Bitwig Studio 2.0 came out a little while ago, as a paid upgrade to Bitwig 1.x.
A new release, 1.3.16 also just came out to fix bugs.

I'm not sure how to the interaction between a tap migration to versions for the 1.x release and a new cask update to 2.0 would work. This seems like it would be a common occurrence with major version bumps. Can I have both a tap_migrations.json entry and a cask of the same name that is a later version, or is it better to not create a tap_migrations.json entry and just update the main repo to 2.0 and add 1.x to versions?

While it won't cause any problems immediately, it's worth discussing how this changes in the future when the brew upgrade command lands. Perhaps something like an addition to tap_migrations that takes versions into account? This might be a Homebrew question then rather than a HBC one. I haven't looked whether HBC handles the cask migration or Homebrew does.

[vitorgalvao]

not create a tap_migrations.json entry and just update the main repo to 2.0 and add 1.x to versions?

For now, that.

While it won't cause any problems immediately, it's worth discussing how this changes in the future when the brew upgrade command lands.

This has been discussed (and is mentioned in the upgrade issue):

For those interested in giving a go at this, take a look at Homebrew/brew#1523. It should give you a starting point (but don’t feel obligated to use it). That specific PR has things that would need to be removed (pin/unpin) and added (take auto_updates into account). If working on it, ideally you could commit to provide some further support for the feature for a little while (just enough to make sure the code itself is stable, not be tied to it ad eternum).

There was an important consideration when thinking about this feature:

You have a commercial app at version 3.2. The developer releases a paid upgrade: 4.0, the cask is updated, and you upgrade. However, you did not want to pay for version 4.0. Now you’re stuck with a version you do not want. Not only is that a bad experience for you as a user, now you’ll likely introduce that last version into caskroom/versions, further filling the repo.

Some solutions were discussed, but ultimately it was argued they might not be needed or be detrimental at this stage, before we have a better understanding on how best to proceed:

(…) we have auto_updates (not yet taken into account in this PR) and I’m thinking: “are there any commercial apps that do not auto-update”? I’m betting those might very well be the minority if they exist (after all, if you ask for more money for upgrades, you want to auto-update so your users get notified).