knossos
knossos copied to clipboard
modrinth
Duplicate changelog entries for multi version mods
Me and quite a lot of developers are uploading the same mod version multiple times for different minecraft versions. While the new changelog page is great, it becomes messy quickly with these types of projects.
I am hoping to see a way to hide/remove certain changelogs from that page without removing them from the version itself.
Even better would be if it compared semver between mod versions and merged duplicates.
Example: https://modrinth.com/mod/cit-resewn/changelog
even worse example.. https://modrinth.com/mod/inventory-profiles-next/changelog up until my last release i was putting full change log in every release
tbh I don't want to go and edit every version....
Same issue over here, currently distributing the same version for up to 5 different Minecraft versions (https://modrinth.com/mod/mouse-wheelie/changelog).
A possible simpler way out would be to just look for consecutive versions with the same descriptions.
A couple of things I noticed, while thinking about how to potentially solve this:
Deduplication
Using semver is not ideal as some mods, for example Iris, don't follow semver in their Modrinth version numbers (they use <minecraft-version>-v<mod-version>: https://modrinth.com/mod/iris/version/1.18.x-v1.2.0).
Just relying on the descriptions is a bad idea, because some mods have automated descriptions (see the bad descriptions here).
Multiple versions in one
If there's a way to deduplicate the versions, then probably all available Minecraft versions with the downloads should be listed.
Another problem: Multi-version releases don't always release everything on the same day - sometimes it takes longer to update one version or a new Minecraft version comes out and gets the update. So the release date and author might differ between associated versions.
Another (temporary) way out
Allowing to filter by Minecraft versions could be a potential workaround.
The problem with that is, that multiple versions belonging to the same MC major version (1.x), might not have the same MC versions defined (e.g. 1.18.2 is mostly incompatible with 1.18.1). When trying to compensate for that, another issue arises: There might be two development strings within one MC version because of that. E.g. I released versions for 1.18.1 and the 1.18.2 snapshots.
Conclusion
Considering all of that, the best simple approach might still be to do some version parsing
IDK Current implementation relies too much on "proper" behaviour by the mod developers... Which apparently is not an easy thing to achieve :lol:
It will much simpler if we can just upload single full change log or 1 per modloader with some special MD syntax to link ### 1.2.3 to the specific version if we want to
Random idea I had without thinking about it too much, add some sort of field to versions that let you specify a "master" version (better terminology needed) that basically meant the specified version's changelog would be used instead. For example, version 1.1.0+1.17.1 could be a master version for 1.1.0+1.18.1, and then these two versions would become grouped and share a changelog. If a changelog is manually added to 1.1.0+1.18.1, its master version will be automatically removed and it becomes ungrouped.
Random idea I had without thinking about it too much, add some sort of field to versions that let you specify a "master" version (better terminology needed) that basically meant the specified version's changelog would be used instead. For example, version 1.1.0+1.17.1 could be a master version for 1.1.0+1.18.1, and then these two versions would become grouped and share a changelog. If a changelog is manually added to 1.1.0+1.18.1, its master version will be automatically removed and it becomes ungrouped.
Yeah, that would be another solution to the problem - I have a similar thing in mind as well (see below).
Just one thing I'd like to bring up about the master approach:
Sometimes even in multi-version mods, there are rogue versions that fix a specific bug on just a selection of the MC versions. Having a master version would require manually adjusting it every time this happens. That's nothing major to do, but it could be simpler imo.
One approach to handle this would be to just define an MC-independent clean version number, like 1.1.0 for 1.1.0+1.17.1.
All versions with the same clean version would be grouped and the changelog could in doubt just be taking from the first released version. Actually, the changelogs for grouped versions SHOULD (as in RFC 2119 :P) all be the same.
Publishing rogue versions would then be completely the same to normal releases.
Since both of these solutions would require changes to the backend as well, this should probably be thought through well, a frontend fix would probably be quicker and enough to quickly fix the unreadable changelogs.
The name clean version is also just prototyping, a better name might be version group.
Won't it be easier to have change log per loader per Minecraft version. The supported minecraft versions are available per file so it won't require backend changes.
Something like that:
How do you determine which versions to show? All major versions? What if a mod is developed for a non-major version?
The supported versions are available for every released file.
So you show all of them I guess or if they are too many just last 2 majors and a More button.
So I guess I need to explain. So every file has information about supported loader and Mineecraft versions. The list of versions is combinations of all the versions supported by all files for that mod loader. And since it might potentially be a big list showing only the latest supported minor for any major and a More button that shows the rest will be better for example:
1.18.1 1.17.1 More...
Random idea I had without thinking about it too much, add some sort of field to versions that let you specify a "master" version (better terminology needed) that basically meant the specified version's changelog would be used instead. For example, version 1.1.0+1.17.1 could be a master version for 1.1.0+1.18.1, and then these two versions would become grouped and share a changelog. If a changelog is manually added to 1.1.0+1.18.1, its master version will be automatically removed and it becomes ungrouped.
I like this the best so far. As for wording in the frontend, "Use changelog from" checkbox which switch from the markdown box to a single textbox
That being said, the ability to sort changelog per mc version / loader would also be cool. Though instead of the "tab" structure, I'd rather a dropdown system like in the redesign mockup:
Also, in addition to the filters above, a "Release/alpha/beta/all" one would also be very useful. Defaulting to release
Filters are available on staging, if anyone has any feedback for this feature, you can let us know in this issue. Still have the duplicate changelog entries to tackle, as well.
Filters are available on staging, if anyone has any feedback for this feature, you can let us know in this issue. Still have the duplicate changelog entries to tackle, as well.
The filtering is looking pretty good, just a small thing I noticed: When clearing filters, the mod loader filter is only visually reset, but the mods don't update. (Tested here - select "forge", then clear the filters)
I'd also like to ramble just one last time about the whole master version idea. Then I'm gonna shut up about it :P
My issues with the master approach:
Chaining
This isn't really a big issue, more of an aspect to consider: If every version can have a master version, that would mean a master version could also have a master version. Resolving these chains would need some additional work when displaying and could lead to confusing results when one version in the middle of the chain unlinks.
1.18--->1.17--->1.16--->1.15
A workaround would be to disallow master versions from having a master and also disallow using versions as master that already are masters themselves:
1.18--->1.17--X-->1.16
1.18--->1.17--X-->1.16--->1.15
This would resolve the chain complexity but increase the complexity in the UI for visualizing these incompatibilities.
Non-existent masters
This is another small issue, but I'd like to at least mention it. When implementing these master versions, I bet that a strict relationship will be enforced, so that a version can only refer to another version that already exists at that point in time.
It can happen that the order of the upload varies for different versions, so there might actually be situations where you'd want to refer to a version that hasn't been uploaded yet.
Of course non-existent master versions could just be denied from uploading which would lead to even more cases where the master version has to be adjusted manually (see below).
Publishing workflow
This is really my biggest concern.
When using (partially) automated publishing methods as Minotaur, you usually have to specify this kind of metadata in the gradle.properties file.
This is already required for stuff like the release type or the supported Minecraft versions.
Adjusting this metadata is an extra step during publishing and is something that at least I regularly already forget about. For the release type and Minecraft versions this is hard to avoid, but I fear that another even more volatile field such as a master version will be added.
It's nothing that is completely undoable but if there's an easier solution from the publishing perspective, then I'd like to opt for that. The version group is usually already available in the environment because it's a part of the version number.
Having to adjust the master version regularly would probably lead to me just not using it at all.
When clearing filters, the mod loader filter is only visually reset, but the mods don't update. (Tested here - select "forge", then clear the filters)
Thanks for letting me know, fixed in dev
