search

negue / meme-box

Manage and trigger media in OBS as a browser source
meme-box.vercel.app
GNU Affero General Public License v3.0
111 stars 16 forks source link

Release version scheme problematic with WiX #528

Open dnaka91 opened 1 year ago

dnaka91 commented 1 year ago

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 :sweat_smile:

negue commented 1 year ago

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 commented 1 year ago

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.