Correct build is not retrieved when using GitHub source

[ItsProfessional]

Description

Baritone makes different releases for specific versions each. The latest release at the time of writing is v1.2.19, which is for 1.12.2. A few releases prior is version v1.10.1, which is for 1.20.1.

Also, in certain releases, only forge or fabric is supported. In other releases, both are supported in a single build.

Ferium doesn't find the 1.20.1 fabric version and just says "The project is not compatible"

Steps to reproduce

1. Run ferium add cabaletta/baritone
2. "The project is not compatible"

Operating System

Linux

Are you using the latest version of ferium?

• I am using the latest version of ferium

Additional Information

No response

[theRookieCoder]

Currently GitHub releases support is pretty finicky, it doesn't check the release description since sometimes multiple assets for different Minecraft versions could be part of the same release. So it only checks the asset filename for the mod loader and game version. Hopefully #155 will allow for more fine-tuned control based on the format of the specific repo's release style.

[ItsProfessional]

Why is the release file name checked? Why not, just download the mod temporarily, check the game version/mod loader from the jar itself, and delete it when using ferium add?

I know it probably sounds overkill, but I mean, there's no other way to ensure that people are going to mention the mod loader/version in the release. Many people will just make an empty release, with no description or anything, with the file name being mod_id-1.0.0.jar

[theRookieCoder]

Downloading all the available files one-by-one, unzipping them, then parsing their contents takes significantly more time than obtaining a single JSON file with metadata about every file available, even if it might not be as complete.