-
Notifications
You must be signed in to change notification settings - Fork 28
Description
Modrinth will provide a version ID slug for the very first "version" that uses a specific version ID. This is documented in the /project/{id|slug}/version/{id|number} API route docs. For cases where multiple versions of a plugin are uploaded that have the same version ID, the oldest version is returned, regardless of whether it is compatible with the server loader or not.
An example (and bug reproduction): PluginDownloadServiceImpl will retrieve https://api.modrinth.com/v2/project/mckotlin/version/1.5.1-k2.3.0 when you try to download a plugin using modrinth("mckotlin", "1.5.1-k${kotlin.coreLibrariesVersion}") in build.gradle.kts. While this would work for a Velocity project, because the 1.5.1-k2.3.0 slug is for a Velocity loader, it will not work for a Paper one. The Paper version is at https://api.modrinth.com/v2/project/mckotlin/version/qmSqbFhr; it doesn't have a proper slug because one already exists for that version in that project.
Many Modrinth plugin developers use conflicting version IDs because there's no way to add different files for different loaders on the same version. Examples include MCKotlin, Chunky, WorldEdit, and Veinminer. There's some plugins that have the loader as part of the version ID (like Simple Voice Chat) but, given the earlier examples, this is never a guarantee.
Ideally, this task should probably first check /project/{id|slug}/version for a matching loader and (ideally) a game version, then download that version, rather than just assuming that the version slug being requested is compatible. This removes the complication of having to search up a slug for a specific plugin version, instead using a better-known version ID. In the case of MCKotlin, it also allows me to dynamically insert the Kotlin version I need as a variable so that I don't need to have a 2.3.0 magic number everywhere in my build.gradle.kts.