Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release version scheme problematic with WiX #528

Open
dnaka91 opened this issue Oct 9, 2022 · 2 comments
Open

Release version scheme problematic with WiX #528

dnaka91 opened this issue Oct 9, 2022 · 2 comments

Comments

@dnaka91
Copy link
Contributor

dnaka91 commented Oct 9, 2022

When working on my Tauri PR #360, I noticed an error when building the installer for Windows. Seems the WiX installer toolkit has some limitation of 256 for the major release number.

Therefore, building 2022.1.0 fails on Windows to a too high number. Also, some tools strictly require a SemVer compatible version, so I had to adjust 2022.1 to 2022.1.0 already.

I know @negue, you went through some different versioning schemes already. So, you're probably not willing to change the scheme yet again. Means we'd have to come up with some solution for this eventually. Currently, I just keep the version to 0.1.0 to make it compile 😅

@negue
Copy link
Owner

negue commented Oct 27, 2022

many companies use "YEAR.SomeSubVersion.SomeFix" it feels a bit like WiX's Fault xD

hmm using 1.2022.1.1 would also look meh, is there any other allowed syntaxes which we can combine in? just for that builder

@dnaka91
Copy link
Contributor Author

dnaka91 commented Oct 28, 2022

Actually, I personally see a date as version scheme extremely rarely. Most software seems to have migrated to Semantic Versioning at some point.

Not saying your versioning scheme is wrong. Just SemVer became so dominant, that most tools expect a SemVer compatible version string. Technically, 2022 as major version is a SemVer valid string, but it's not SemVer compliant in the sense of when to bump specific version parts.

So I can kinda understand that WiX has a limit there (although, they don't really need to), because it's unusual for a typical SemVer major version to ever be that high.

I totally understand that SemVer is a bit more tricky for applications. For libraries, it's easy, patch for bugfixes, minor for any API compatible changes or additions, and major for any breaking API changes. Although even there, sometimes there are breaking changes without actually changing the API (like internal changes that modify the behavior of the library, thus changing the outcome despite the same API).

And for applications it's rather arbitrary. Sure patch bumps for bugfixes again, and mostly minor version bumps for regular releases, but when to bump the major version. Most applications seem to bump the major version for rather big revamps of the app or really large new features.

In the end, it's totally up to you. Just saying, you could just go with a regular SemVer instead of a date encoded in a SemVer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants