-
Notifications
You must be signed in to change notification settings - Fork 27
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
Support extended semver for mod versions #634
Comments
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 As a shorter term alternative, you could try to append the rc number to the patch version, ex |
This doesn't work since now you have a patch version of 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 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. |
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). |
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
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. ^^ |
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 be1.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
:The text was updated successfully, but these errors were encountered: