Modrinth Game Versions badge doesn't fetch all game versions

[Ceedrich]

Are you experiencing an issue with...

shields.io

🐞 Description

When using the Modrinth Game Versions badge, you would expect to get all supported game versions, but you only get the ones from the latest release

🔗 Link to the badge

https://shields.io/badges/modrinth-game-versions

💡 Possible Solution

The fix would be relatively simple. Only the function async handle({ projectId }) in services/modrinth/modrinth-game-versions.service.js would need to change from:

  async handle({ projectId }) {
    const { 0: latest } = await this.fetchVersions({ projectId })
    const versions = latest.game_versions
    return this.constructor.render({ versions })
  }

to:

...
  async handle({ projectId }) {
    const data = await this.fetchVersions({ projectId })
    const versions = [...new Set(
      data.map(ver => ver.game_versions)
          .reduce((prev, curr) => [...prev, ...curr]))
    ].sort()
    return this.constructor.render({ versions })
  }

[chris48s]

I don't think I agree with this. In general, our platform and version support badges show the platform and version support for the latest version of the package. So for example: If I request https://img.shields.io/pypi/pyversions/django that shows me the python versions supported by the current version of django, not every python version django has ever been compatible with over its 14 years of releases. If I request https://img.shields.io/node/v/got that shows me the node version constraint for the current version of got, not every node version django has ever been compatible with over its 10 years of releases. Sure there was some old version of got that is compatible with node 12, but you don't want to be running it. If you take into account every package version, you basically just tend over time towards listing every version of the platform. Is there some property that makes modrinth different in this respect? My instinct is no.

[Ceedrich]

I agree that, in most cases, you want only the versions compatible with the latest versions. However, in minecraft, you have to release a different package for the different minecraft versions. A mod might get a feature update that is ported to multiple minecraft versions with multiple packages. Consider the following procedure (top to bottom):

Mod Version	Minecraft versions	Comments
v1.0	1.19	first release
v1.1	1.19	feature update
		New Minecraft Version
v1.1	1.20	Port to Minecraft 1.20
v1.2	1.20	Feature update to 1.20
v1.2	1.19	Feature update to 1.19

After that, the badge would only show the minecraft version 1.19 even though the newest version (v1.2) also supports 1.20 which is arguably more important, since most people play on the most recent version of minecraft.

Therefore, the optimal solution would be, to only show the game versions of the most resent version v1.2 which, in the example case above, includes the two most recent versions.

Since there are no waterproof ways to figure out the latest (feature) version of the mod (different authors version their mods differently, the only version not controlled by the author is the game version), I would prefer showing all the versions (or limiting the badge to showing only the latest five versions as this is the maximum anyways).

[chris48s]

OK. Thanks for the extra context.

@PyvesB - as our resident minecraft expert, could I tag you in on this one?

Also, @Ceedrich - could you give us an example of a modrinth Project ID or two that has this issue so we can see what the API responses look like?

Another thing I will note here is: Because of the solution we adopted in https://github.com/badges/shields/issues/10346 this doesn't deal particularly well with really long lists of versions. Once there are more than 5 versions in the list, some data is missing.

[Ceedrich]

The issue is present in some of the most popular mods:

Sodium link to Endpoint Iris link to Endpoint Entity culling link to Endpoint (Even with releases of the same version for different mod loaders)

Concerning #10346, unfortunately there is no consistent way to version numbering when it comes to minecraft mods. Many use a pattern similar to $modVersion-$gameVersion or $gameVersion-$modVersion but there is no generally accepted schema.

However, Modrinth lets authors feature certain versions. A solution could be to filter the response by this featured key. That way, all the relevant (based on the author’s opinion) versions are considered when showing the badge.

Edit: Modrinth features certain versions automatically, so this solution would work even for authors that do not bother deciding which versions to feature.

If you do not manually feature any versions on your project, Modrinth will automatically feature certain versions that are likely to be relevant to users. The latest version of any given combination of game version and loader will be automatically featured by this system. For example, if you have a version for Fabric and Forge, both will be featured; likewise, if you have a version for 1.19.4 and 1.20.1, both will be featured.

from https://support.modrinth.com/en/articles/8793360-version-auto-featuring

[chris48s]

OK. I do now understand the issue.

Featured versions suggestion sounds like it could be reasonable. I think I'll see if P-Y has any thoughts on this one before proceeding.

Thanks

[PyvesB]

Out of interest, how are these featured versions rendered in the Modrinth UI?

[chris48s]

Couple more thoughts on this:

1. This is a bit of a tangent, but our modrinth version badge just picks the first version and says that is the "latest" https://github.com/badges/shields/blob/5198a4142f0111d299074d8ddac02b1c8d50a283/services/modrinth/modrinth-version.service.js#L28-L32 Given the way versions work in this community, is that actually the right model?

2. Just looking at https://modrinth.com/mod/sodium and https://modrinth.com/mod/entityculling as examples it appears that the registry does present Minecraft compatibility across all versions