Consider removing build number from release asset
I'm trying to get SwiftBar updated in Homebrew and ran into 2 issues:
- The method recommended by the contributing guide to update a cask,
brew bump --open-pr swiftbar, didn't work because it was looking for the release asset with build numberb520from 2.0.0, while 2.0.1 usesb536, so I had to create the PR manually. - One of the required verification steps,
brew audit --cask --online swiftbar, fails for presumably the same reason.
If the build number were removed from the filename, that would make automation tasks like this easier to set up.
You are saying that having a stable SwiftBar.zip will help to address this issue?
SwiftBar.v2.0.1.zip, without the b536 part, should also be fine. The version number is already required to build the full URL after all.
Updated in the latest release, so you can give it a try.
I would need to update the Sparkle thingy, but that shouldn't be too much work.
Thanks, I can't test it anymore because the PR already exists now, but we'll know for sure on the next release after 2.0.1.
Think this may have caused an issue with being able to update or install via homebrew?
https://github.com/swiftbar/SwiftBar/releases/download/v2.0.1/SwiftBar.v2.0.1.zip
vs
https://github.com/swiftbar/SwiftBar/releases/download/v2.0.1/SwiftBar.v2.0.1.b536.zip
Looking at https://github.com/swiftbar/SwiftBar/releases/tag/v2.0.1 it seems like the release asset name was reverted to include the build number again. I had removed it from the Homebrew PR (https://github.com/Homebrew/homebrew-cask/pull/203229) following https://github.com/swiftbar/SwiftBar/issues/433#issuecomment-2689354744.
@melonamin Was this intentional? Should we adjust Homebrew to include the build number again?
@fenhl Yeah, I did it yesterday on the go and forgot to comment here; sorry.
Autoupdate relies on this versioning scheme, and there is no easy way to fix it, so we're stuck with it for now.