ArchipelagoMW
Core: Support Full Semver in world_version Manifest Field
What task needs to be completed?
From the discussion in the API update thread, it seemed inconclusive regarding supporting world_version fields that had non-numeric parts and/or extra information not limited to major.minor.patch. This includes things like -tags which are included in the semver specification.
I personally use a versioning scheme defined in my APWorld that has an optional tag for a beta, as defined here. I am currently unable to mirror my versioning scheme in the world_version field of the manifest. This is extremely inconvenient, and also leads to a mismatch between the two places where the version is defined in my apworld.
I've heard similar things from other people surrounding this.
Functionally, supporting full semver is easy on the python side (just have to implement comparisons for handling the string tags). I believe the main concern brought up was being able to support it within an eventual database solution for apworld management. Not sure what the stack there involves.
Since I've seen multiple AP devs incorrectly claim that there's no solution to sorting/ordering versions with tags, I think it's worth highlighting here that semantic versioning has always specified tag order: https://semver.org/#spec-item-11
And the Python semver library even has unit tests on this exact part of the spec: https://github.com/python-semver/python-semver/blob/cc5b1d370f74c7a1775da5cfcbaca954bbb9f3bd/tests/test_compare.py#L49-L73 so it's not some obscure detail no one implements.
https://github.com/ArchipelagoMW/Archipelago/pull/3809/commits/005c39c50e4bd273cb16adda8819fe56ced2d20a#diff-270ef688d35e8098bd9c54307af68c28a61bbb14599bf52af56c689c27d0e973R37 has an approach that makes sense to me, and would also benefit core itself for the ability to differentiate the RCs from the regular builds
I don't use SemVer for my versioning (so forcing it is inconvenient), but allowing for better specifics with semver will allow me to have an internal version representation that I can't do in the current system that I can do in .NET (0.2.1.2).
I feel like I should point out that the request is to support the full format of a semver version number, not enforce the semantic meanings.
In my world manager, I've been parsing versions with packaging.version.Version, which supports the full range of pip's version schema. While we probably don't need everything it supports (I sure hope nobody ever uses Epoch in their version numbers), it does support the two things people are wanting from this proposal: rcN and -localversiontag, and should be very easy to switch over to.
I feel like I should point out that the request is to support the full format of a semver version number, not enforce the semantic meanings.
In my world manager, I've been parsing versions with
packaging.version.Version, which supports the full range of pip's version schema. While we probably don't need everything it supports (I sure hope nobody ever uses Epoch in their version numbers), it does support the two things people are wanting from this proposal:rcNand-localversiontag, and should be very easy to switch over to.
Yep. This is exactly what I was trying (and somewhat failing) to say in the original comment.
The comparison logic in the linked example from sims is not what's needed from core, only what was mentioned above.