Proposal to Standardize Release Tagging Using Semantic Versioning

[cdwmhcc]

Description

Dear Scroll Reverser Developers,

First of all, I would like to extend my gratitude for your contributions to the open-source community through the Scroll Reverser project. I have noticed an inconsistency in the version tagging within the releases section that could potentially confuse users trying to track changes or understand the progression of releases.

Examples of Current Version Tagging

Here are a few examples from the Releases page that illustrate the current inconsistency in version naming:

• v1.9
• b10528
• b10527

Suggestion

To enhance the professionalism of the project and improve user experience, I recommend standardizing the version numbering format by adopting Semantic Versioning (SemVer). Semantic Versioning is a widely recognized standard that uses three segments of the version number (MAJOR.MINOR.PATCH) to reflect different levels of modifications between releases. Here’s how it could look:

• 1.9.0 instead of v1.9
• 1.10.0-alpha.1
• 1.10.0-beta.1
• 1.10.0-rc.1

This formatting not only clearly communicates the nature of changes between versions but is also compatible with various tools that automate version control and release management, facilitating better project maintenance.

Conclusion

I hope you will consider this proposal to standardize version numbering. I believe adopting SemVer can significantly streamline development workflows and help both contributors and users to better understand the significance of each release.

Thank you for considering this suggestion, and for your continued work on this valuable project.

[pilotmoon]

Thank you for your suggestion.

If it will help your understanding of the tagging:

Tags beginning with "v" are Production releases, with the manually chosen version number. These follow a roughly major/minor/bugfix approach though to be honest, the exact number chosen is more based on my whim at the time. (I don't think a strict semver approach really has benefit for a user facing app, like it has for a library.)

Tags beginning with "b" are beta releases and use a monotonically increasing, automatically generated build number. Think of the beta and production releases as different "release channels".

[cdwmhcc]

Thank you, @pilotmoon, for providing insights into the current versioning approach used in Scroll-Reverser.

I appreciate the flexibility offered by the current system, but I'd like to highlight a challenge it poses for automated tools like the one I'm developing, which is similar to Homebrew (App update detection). These tools rely heavily on a predictable and standard versioning scheme to manage dependencies effectively.

The use of different tags like v1.9, b10528 introduces a level of ambiguity that complicates version parsing and can lead to potential mismanagement of versions or dependency resolution issues in such tools.

Thank you for considering this feedback. I believe that a slight adjustment to the versioning strategy could enhance integration with tools and platforms, benefiting the broader community relying on automated setups.

Because English is not my native language, there may be some misunderstanding, if there is any, please forgive me, I respect the idea of ​​your work very much.

Looking forward to your thoughts on this.

[pilotmoon]

My view is that tags on a repository are an internal management matter and not a publicly facing versioning system.

In SR's case we have appcasts which are the publicly facing XML streams of releases. There are two appcasts, one production releases only and one that also contains beta releases.

Example:
https://softwareupdate.pilotmoon.com/update/scrollreverser/appcast.xml

As you may also be aware, Mac apps have two version indicators in their Info.plist, the CFShortVersionString and the CFBundleVersion.

The short version string is the string like "1.8" or "Build 10520" whatever the developer chooses.

The bundle version on the other hand is monotonically increasing integer. It is this integer that actually forms the release version which you can depend on when comparing versions.

[cdwmhcc]

Thank you for your response, @pilotmoon.

I understand that our scenarios differ, which might lead to some misunderstandings regarding versioning needs.

Your scenario: Users rely on the built-in update detection to install stable versions. Those requiring testing versions can manually download the beta versions prefixed with 'b' from the GitHub Releases page.

My scenario: I automate the retrieval of different versions like rc, beta, and dev from GitHub Releases. Through a UI interface, I recommend the Scroll-Reverser app to users, who can then choose from various versions such as 'nightly', 'dev', 'alpha', 'beta', 'rc', 'preview', or 'stable' based on their needs.

Regarding the Info.plist, it requires installing the app into the macOS system to inspect, which is a separate concern from what we are discussing here. This step is something that needs to be handled on the client-side.

I recognize that for most users, using stable versions is sufficient. If this proposal does not bring any substantial improvements to the Scroll-Reverser project, I am willing to exclusively use the stable versions and forego the others.

Thank you once again for considering this feedback. I greatly respect your work and the decisions you make regarding the project.

[pilotmoon]

You can always treat "b" tags a beta and "v" tags as stable, if you want. I wish you luck with your project and I will close the issue now. My tagging system is convenient for me and integrates with my build scripts and release processes, and I don't see a compelling reason to change it.