Support extended semver for mod versions

[GeckoEidechse]

Currently mod version in manifest can only be MAJOR.MINOR.PATCH. This prohibits cases like uploading release candidate versions of mods.

For example, for Titanfall2+Northstar we were planning to add a second Thunderstore package for release candidates. This means we'd have a package with the version 1.9.1-rc1. A subsequent updated release candidate would then be 1.9.1-rc2. However version numbers like this are not permitted on Thunderstore, even though they are valid semver.

Error message when uploading a package with 1.9.1-rc1:

[Windows10CE]

Mythic would need to comment here for his most current views, but from past conversations about the issue (none here on GitHub as far as I know) I can say this much:

Supporting the designation of "prerelease" software is something that Thunderstore should do, but it hasn't been decided whether that will be done by supporting extended SemVer (the - for prereleases and + for build metadata) since it creates extra complexity downstream when trying to parse and compare version info (and it would also be a breaking change to the manifest format).

As a shorter term alternative, you could try to append the rc number to the patch version, ex 1.9.101.

[MythicManiac]

As a shorter term alternative, you could try to append the rc number to the patch version, ex 1.9.101.

This doesn't work since now you have a patch version of 101 (a whole integer), which is not the same as 0.101 (decimal) which you probably thought of. It'd break the version comparisons as 101 is larger than 1

I'd suggest shamelessly bumping patch numbers on the test channel instead of relying on suffixes, and finally only publish the versions that are deemed stable to the stable channel.

For example, instead of 1.9.1-rc1 and 1.9.1-rc2 you could simply do 1.9.1, 1.9.2, 1.9.3 ... until you reach a stable point, say 1.9.4. Then release only that version on the stable channel and omit versions 1.9.1 through 1.9.3 as they didn't make the cut. In other words, the stable channel would be missing some versions from the version history, as you'd only push the stable & ready versions in there.

This is of course assuming you want to keep parity between the stable & test channel versioning. If you don't care about that, this isn't really a problem at all, as you can simply use differing version numbers on the channels.

[MythicManiac]

Adding to this publicly what was discussed on Discord:

This is a feature that several developers have requested (support for pre-releases or other alternative release channels), but we haven't decided what we want to do about it yet.

On the surface the suffix support requests seem to originate from some developers already being used to using them to solve an issue, but it doesn't seem like a lack of version suffixes in itself is an issue. Chances are we'll evaluate what the actual root cause problems are that developers are facing and trying to solve, some by employing the version suffix notation, and address that root cause directly.

In any case, we've not ruled out extended semver support, but it does have tradeoffs on the complexity department. Many newer developers are having a hard time understanding the strict semver syntax as it is, and any extra complexity added will increase the likelihood of bugs in all of the ecosystem-wide tooling (including what 3rd party developers create).

[GeckoEidechse]

This doesn't work since now you have a patch version of 101 (a whole integer), which is not the same as 0.101 (decimal) which you probably thought of. It'd break the version comparisons as 101 is larger than 1

The solution @Windows10CE mentioned would still work for us (Northstar) as we are planning to make an entirely separate package for release candidates. So in our case it's fine for 101 to be larger than 1 as they are not compared directly to each other. There will of course be players seeing the two different version and selecting simply the one with the bigger number but that's something we can address to some degree in PSAs, add additional logic to our Northstar specific mod-managers and simply by always linking to stable package when referring to Northstar on Thunderstore :P

On the surface the suffix support requests seem to originate from some developers already being used to using them to solve an issue, but it doesn't seem like a lack of version suffixes in itself is an issue. Chances are we'll evaluate what the actual root cause problems are that developers are facing and trying to solve, some by employing the version suffix notation, and address that root cause directly.

Basically this yeah. If a release channel system is incorporated into Thunderstore that allows for release-candidates and rolling dev releases, there's no need to also add suffix support from extended semver. Extended semver to me just seemed like a lower hanging fruit and therefore easier to implement but there are of course issues as you mentioned that I did not anticipate. ^^