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

Change in Modrinth versioning breaks tools #3716

Open
copygirl opened this issue Aug 26, 2022 · 3 comments
Open

Change in Modrinth versioning breaks tools #3716

copygirl opened this issue Aug 26, 2022 · 3 comments
Labels
status: fixed in next release Issue will be fixed in the next release

Comments

@copygirl
Copy link

packwiz uses the version number field on Modrinth, parsing it as SemVer, to compare which version it should consider newer when updating or initially adding a mod to a modpack. You appear to have recently changed the format of the version which breaks, as 1.18.2-0.5.0c is considered "greater" (or "newer") than 1.18.2-0.5.0.d, as per SemVer specification ("Numeric identifiers always have lower precedence than non-numeric identifiers", and 0c is non-numeric).

It wouldn't be advisable for packwiz to just go by timestamp, because versions could be uploaded out of order. This could happen for example happen when older, already existing versions of a mod are uploaded to Modrinth by the author.

I'd say the new "format" is better than the previous, since the old one would run into issues if you get into multi-digit territory. So it just is the way it is now. But I do want to note that it would be advisable to move to Semantic Versioning fully:

  • If the current format was parsed as SemVer, 1.18.2 would be the version, and 0.5.0.d the pre-release identifier. Therefore, on Modrinth, leave out the Minecraft version in the version number field, as that's already available as part of the metadata there. You can of course still include it in the .jar file name.
  • I don't see a benefit in using a letter, other than personal preference. Your 0.5 releases could just as well have been labelled 0.5.0, 0.5.1, 0.5.2 and so on. There is also no shame in using a positive major version even if you don't consider the mod near feature completion. Major version changes suggest breaking changes, which you've already gone through.
  • If you insist on including the letter, but still want to leave out the Minecraft version, to be valid SemVer, you'd have to use for example 0.5.0-d. Though note that the d here is a "pre-release" section. Usually, one would denote pre-release for example with 0.5.0-alpha.1, 0.5.0-beta.1, 0.5.0-pre.1 or 0.5.0-rc.1, before moving to a stable version 0.5.0.
  • Though likely obvious, to avoid further issues, I'd suggest this change to be made with the next major Minecraft version.

See also: packwiz/packwiz#149

Thank you for your work. 💚
Sincerely, an ex-modder, SemVer advocate, and writer of a SemVer parsing library.

@github-actions github-actions bot added the 1.18 label Aug 26, 2022
@copygirl
Copy link
Author

I gave this another thought. It's unlikely you will get to a version 0.5.10a or so. Perhaps you could go in and change the version number on Modrinth back to the old format for the sake of compatibility? Just for the time being, until you adopt a new format for the next major Minecraft version.

@IThundxr
Copy link
Member

Interesting yeah, the versioning is off and this should definitely be changed, i've left a message for other's to look at so this can be fixed sometime soon

@IThundxr IThundxr added the status: confirmed Issue's details are known, it is consistently reproducible, and it needs a fix label Mar 14, 2024
@IThundxr
Copy link
Member

For lack of a better tag at the moment im gonna dropped confirmed on this so i don't forget to check back on this later

@IThundxr IThundxr added status: fixed in next release Issue will be fixed in the next release and removed status: confirmed Issue's details are known, it is consistently reproducible, and it needs a fix labels Jan 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: fixed in next release Issue will be fixed in the next release
Projects
None yet
Development

No branches or pull requests

3 participants