Pre-release versioning and updater compatibility

[HugeIRL]

First off, thanks for the work on BetterDisplay. It’s a great app and clearly very actively maintained.

I wanted to start a discussion around how pre-release builds are currently versioned and how that impacts macOS update tooling.

At the moment, preview builds use the same version string as stable releases, for example 4.1.4. From a tooling and user-expectation standpoint, this makes it hard to reliably distinguish preview versus stable builds.

Many macOS updater apps, including tools like Updatest and other automated scanners, rely on semantic or string-based version comparison. When previews share the same version number as stable releases:

• Preview builds are treated as stable by default
• Users can be offered preview builds unintentionally

Using a standard pre-release suffix would solve this cleanly and aligns well with common semantic versioning expectations across the macOS ecosystem. For example:

• 4.1.4-preview
• 4.1.4-beta.1
• 4.1.4-rc.1

This does not require changing internal versioning or release cadence. It simply makes preview builds explicitly identifiable at the version-string level.

Clear pre-release versioning helps updater tools correctly classify releases, helps users understand what they are installing, and reduces accidental preview installs and related support issues.

Totally understand that this may have historical reasons, but I wanted to raise it since more users now rely on automated update tools rather than manual downloads.

Curious to hear your thoughts on this.

[waydabber]

Hi there,

Is this about the GitHub tag or the naming of the actual downloadable file?

Normally pre-release versions are marked as pre-release in GitHub, but the tag itself does not have this differentiator. Sometimes the app dmg has "-pre-release" in the naming if the binary was compiled with a pre-release flag, but I regularly create versions that are release candidates and provide them as pre-releases initially and if all works out, I just remove the pre-release tag from the GitHub release and reclassify the binary.

For example currently we have a v4.1.4 version, which is marked as pre-release in the Sparkle update feed and GitHub, but compiled as stable release (this is how the version self-identifies in the "About" section) and is actually linked as latest version on the main GitHub page for those who newly download the app. If there is nothing weird in macOS 26.3 RC, then this version should be promoted as the proper latest stable release.

The best source of truth actually is the Sparkle update feed (https://betterdisplay.pro/betterdisplay/sparkle/appcast.xml) for BetterDisplay, where internal pre-releases, pre-releases and stable releases are properly indicated (using the channel tag) as this guides the auto-update mechanism the app normally uses. It would be best if Updater apps could use this sparkle feed. It also has every relevant information.

[waydabber]

But I want to note that generally there is no much harm if an updater app pushes a GitHub release dmg that does not have the string pre-release in its file name - these versions are usually fine and (they are potential stable versions) which went through multiple internal pre-releases so they rarely have serious issues (in case of a serious issue they are followed up with an update shortly).

[HugeIRL]

Hey @waydabber sorry I meant your Info.plist bundle versioning.

And the good news is we do! We use the sparkle feed and channels which you've set up correctly however for features that have a server backend and aren't using Sparkle (think in the past like MacUpdater), we can't use sparkle channels as a way to differentiate versions which is why I made my suggestion! 🙂