Dependencies on Minecraft ~1.20 and ~1.21 do not work as you expect it to as Minecraft does not follow semver. Instead restrict it to exactly 1.20.1 and 1.21.1.

Relevant lines:
https://github.com/The-Aether-Team/The-Aether/blob/1.20.1-fabric-develop/src/main/resources/fabric.mod.json#L45
https://github.com/The-Aether-Team/The-Aether/blob/1.21.1-develop-fabric/gradle.properties#L22

Could you elaborate what you mean by not working?

I've seen some users ignore the metadata on Modrinth/CurseForge and run the 1.20.1 version on 1.20.6, or run the 1.21.1 version on 1.21.4. It obviously crashes but it's good to have a Minecraft version constraint to prevent it from crashing and to tell them which version they need.

The issue is the ~.

The fabric version dependencies are kept less strict in case of minor mc updates that don't have breaking changes that the mod can still be compatible with. The downloads have this info labeled and the primary version in the file name has this too so I don't really see this as worth it to implement a change for.

I talked to the Fabric folks about this. They advise that you just publish a new build should Minecraft release a hotfix. And that's why I tell modders to tighten their Minecraft dependency.

I guess I can look into it at some point when possible.

Okay first Minecraft dose stick to Semver even if the community states they use such incorrectly as they only use Minor and Patch numbers to indicate updates. The ~ as found with FLoader here is a addition to many people who implement SemVer allowing for the patch number to ignored for the most part allowing a wider range until a minor version bump.

Its use here is because of the recent rapid updates that tend to lead to a major release followed by a bug fix update causing issues with quite restrictive versioning. This means it will require another update to be pushed when such is not required instead of just using Modrinths and Curseforges built-in method to indicate Minecraft Version compatibility.

Overall this problem is not something that needs to be solved as most of all Non Mojang launchers handle such with proper checks on Curseforge and Modrinth. Users who actively ignore what versioning a given Mod can be used when downloading and finding it crashing without checking what Version they downloaded may be best to use a custom launcher to handle these checks rather than themselves. Ultimately I believe the use of ~ here is fine and people who actively ignore metadata will have to learn these checks or use a launcher to handle it for them.

The version number is compliant with the SemVer standard but it does not mean that such is used like the standard suggests.

I also wish people wouldn't ignore CurseForge and Modrinth metadata.

Then educate users or tell them to use launchers from CurseForge, Modrinth, or even PrismMC to handle this for them. From the discussions I have this is not an uncommon thing to do with versioning and frankly, the Fabric folks I have talked with do not find this as an improper use of ~ for what the goal is.

Like ideally a better solution to this is for loaders to provide a unified API target version that bumps based on the relative amount of changes for the given Minecraft update i.e. 1.21.61324 (Number based on 1.21 release) that covers 1.21 - 1.21.1 as 1.21.2 contains a good deal of breaking changes. Constant releasing of mods for updates to the mods FMJ is kinda ridiculous as everyone would make unneeded releases for bug fix updates.

Minecraft dose stick to Semver

What???

I'm aware of how ~ works. It's too permissive. And we're already past 1.21.1; we know 1.21.2 breaks things. Fabric doesn't do any magic to make Minecraft SemVer compliant and so ~ doesn't work the way you say it does.

I also wish people wouldn't ignore CurseForge and Modrinth metadata.

If a modder can change CF/MR metadata, a new version can be compiled trivially.

Ultimately I stand with the fact that the use of ~ is fine and people should use the metadata provided but if @bconlon1 wants to change such, go for it.

The version number is compliant with the SemVer standard but it does not mean that such is used like the standard suggests.

I think I get what you're saying but that doesn't mean it's actually compliant with it.

Like ideally a better solution to this is for loaders to provide a unified API target version that bumps based on the relative amount of changes for the given Minecraft update

Having an exact dependency and updating was the response to that suggestion by some Fabric people. Not sure what to search for in the Fabricord but it's in toolchain-other.