DevToys Preview 2.0.1

[veler]

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.

---

[krehel]

Hi @veler -

Based on this Devtoys issue that you're engaged on, it seems you are now the successor to the current DevToys Cask. It probably makes sense to utilize the existing Cask and refresh the urls, versions, etc rather than creating new.

Unless there is some other reason?

[veler]

Hi @veler -

Based on this Devtoys issue that you're engaged on, it seems you are now the successor to the current DevToys Cask. It probably makes sense to utilize the existing Cask and refresh the urls, versions, etc rather than creating new.

Unless there is some other reason?

Hi @krehel ,
I'm indeed the new owner of it. I'm about to release DevToys 2.0 as a beta version. I'm very new at Homebrew and from my understand of the documentation, it sounded like it was a good idea to publish unstable builds in a different Cask. Is that correct?

Also, this PR is currently in Draft because the Release on my GitHub is draft and not publicly available yet, meaning that for now, commands like brew audit --cask --new and other are failing.

[krehel]

No worries @veler! Happy to help and support. Some thoughts -

I'd say unstable builds would go in a different Cask if you're going to consistently publish beta / daily / nightly builds (whatever not mainline releases) ahead of your stable builds that you want separated. Such as VS Code and VS Code Insiders.

Some Casks publish stable builds multiple times per day and don't do a separate daily or beta schedule at all.

For your situation here's some options -

1. If you just want to do a handful of one-off beta builds (assumption: if I'm wrong please tell me) before switching to a standard stable release cycle, then we could mark the existing Cask to allow pre-releases (if you're tagging them as such) and then drop that label once you're finalized, at which point it would essentially follow normal releases.

2. You could mark your "betas" as proper GitHub releases, and we update the Cask to point to your repo. Use something like version 1.99.xx or whatever. That more depends on your style of releasing. Takeaway: as long as your versions continue increasing, we'll pick it up as newer.

3. We do what you're planning here, and keeping split builds. But really only if it becomes a consistent build and release channel away from stable builds.

Note the @suffix is not an often used construct, a relatively small percentage of casks provide alternative versions. (195 out of 6927 casks, measuring today)

I guess it also depends how many people you're trying to get using DevToys beta whether you're cautioning the beta, or you find it's stable for daily driving but finalizing details.

If you're confident in the current beta, I'd probably opt for the second option. From an end user perspective, both 1 and 2 would push the beta to them for testing. It's just more semantics on your release tagging. Option 3 obviously retains the release split.

I'm not trying to tell you how to run your project though please bear in mind. ❤️

(n.b. I use DevToys on Mac and Windows, happy to test)

[veler]

Thanks for these insights @krehel, this is super helpful!
With consideration of what you said, options 1 and 2 are indeed interesting. Here is how I feel:

1. Playing a bit with DevToysMac, the app is much behind DevToys Windows in term of features, tools and stability.
2. I played with DevToys 2.0 on Windows, Mac and Linux for weeks now and it's pretty stable, although still a "preview" because who knows how it will be on customer's machine.
3. I definitely want make DevToysMac users adopting the new app.

With that in mind, option 1 and 2 sound viable to me. I'm not sure to follow the difference between both though. Here is how versions are handled on my side:

1. Simply increment the Revision (4th digit) in the version number
2. Mark it as preview or not when building, and mark it as pre-release or not in the GitHub release.

Once we reached stable 2.0 release, as user count grow, further updates may or may not go to a preview channel based on how confident we feel with changes. But that's quite an unknown for now.

What would you recommend based on that?
Thank you so much again ! 🙏

[krehel]

With that in mind, option 1 and 2 sound viable to me. I'm not sure to follow the difference between both though. Here is how versions are handled on my side:

1. Simply increment the Revision (4th digit) in the version number
2. Mark it as preview or not when building, and mark it as pre-release or not in the GitHub release.

I probably made this more complicated than needed. 😀

tl;dr: release 2.x.y.z like a normal latest version, w/o pre-release.

More below: ⬇️

---

I'd say the simplest way is to mark your "beta" releases as just standard latest releases for the time being and keep standard version incrementing. If you're doing 2.0.0.x, fine. As long as "x" continues to increase as you release (i.e. it looks like semver), we can bump the version. If you go back and revert to 2.0.0 as a "final" version, it's going to appear as a regression in version.

We don't usually take GitHub pre-releases unless expressly needed. We typically only do it for applications that mark everything as a pre-release. Most applications we filter out occasional pre-releases by looking for GitHub latest in a repository to prevent end users from getting those versions.

Again, I emphasize: not telling you how to run your project. You can build hourly releases as stable if you want of course. 😅

But given what I gather:

1. seems to be a temporary "beta",
2. you want to push the app out for wide adoption
3. you feel it's stable
4. you're incrementing in the 2.x.x tree

If you make a release marked as GitHub latest, 2.x.x.x, and we update the existing Cask with your repository information - on an end user update they will pull your version, no hassle with pre-release and exceptions.

[veler]

That's awesome!

If you're doing 2.0.0.x, fine. As long as "x" continues to increase as you release (i.e. it looks like semver), we can bump the version.

That's exactly how we do.

If you go back and revert to 2.0.0 as a "final" version, it's going to appear as a regression in version.

Yep, we do NOT do that.

Given your advice, I updated the PR to update devtoys.rb directly. Thank you so much for your help here, I really appreciate!
Again, for now, I'm unable to run brew audit --cask --online and similar commands as the release isn't public yet. I will run these commands as soon as possible, and when ready, I will publish this PR.

[bevanjkay]

Thanks @veler - I have left some comments in the review to help for when you're ready to do the updates.

[veler]

@bevanjkay , really appreciate all your feedback, thank you very much!

[veler]

Hi @krehel ,
Thank you again for your precious help! It seems like it's good to go. I would like to wait Tuesday morning to complete the PR. Can we ensure I and only I can merge this PR when I feel so?
Thank you :)

[bevanjkay]

You should revert it back to draft status then. But merging requires someone with the branch permission, so that will need to be a maintainer.

[veler]

I see. Nevermind then. Let's merge it as soon as possible 😅

[krehel]

We will need to remove this from pre-release allow list once this goes stable. Thought we weren't going to use pre-release labels.

Merging PR...

[veler]

We will need to remove this from pre-release allow list once this goes stable. Thought we weren't going to use pre-release labels.

Merging PR...

I will maybe sur to remove it once not in Preview anymore. Thank you so much!