The current fabric api modules use a module version + the commit hash.

Issues
Fabric Loader doesn't infact, ignore the metadata, and treats it as different versions, and Fabric Loader will proceed to load it from comparing the hash of the version string (hashCode the entire string!), at this point it is just gambling. However this can be easily fixed and really isn't much of an issue that way.

Gradle doesn't understand hashes, when you have a dependency that transitively provides Fabric API, Gradle is just doing random stuff that I don't think I understand now.

Issues that hashes solve (According to modmuss)

Preventing overrides on existing versions.

Isn't Gradle non overriding as default? Don't need to add -SNAPSHOT to make it change?

They prevent identical versions released twice

But they are identical versions, why do you want them distinct versions? Ideally any changes, including just a small typo fix in a mixin or whatever should have a version bump

They are only metadata, should be ignored

Build numbers are flawed as well, also isn't this just fixing the issue this just created?

They work across branches unlike build numbers

No metadata or consistent metadata is imo better than both hashes and build numbers, metadata like game version is fine because they are pretty consistent

It's been my opinion for a long time that Fabric's versioning scheme is ambiguous, error-prone and overly complicated in service of hypothetical ideals vs practical use cases.

I'd favor MC-specific distributions tied to MC-specific branches (easier for consumers to understand and easier to support, even if they do happen to work across MC versions) and updating patch numbers based on commit activity. Wouldn't stress even a tiny bit over skipping patch numbers, either.

But I tend to be simplistic in my build habits and Fabric generally steers the other way. I have no expectation anything like that will be adopted.

Isn't Gradle non overriding as default? Don't need to add -SNAPSHOT to make it change?

From what I know this is maven dependent, like maven central and jcenter would not let you do this but modmuss’s maven would. This is fixable by automatically incrementing the version though.

But they are identical versions, why do you want them distinct versions? Ideally any changes, including just a small typo fix in a mixin or whatever should have a version bump

So this is the part i never got a full response on, but I have concluded hashes have some dark sorcery that allow them to detect changes. So if you increment using e.g date/time you would have different files for the same classfiles but with hashes the files would be the same for the same classfiles.
SO this leads me to some more guessing: Api’s publish script publishes every module whenever any module changes (Facts that support this theory: according to Modmuss Fabric Api’s publish script is very slow, hmm)
In that case the solution is simple. Calculate the hash, purely for the purpose of knowing if something changed in a module, and if it did, increment a normal, reasonable semver patch version, and publish that module only.

You didn’t mention the problem of branches. This is solvable by adding -branch to the version (it also makes it much easier to know what you need, this part is needed no matter what, honestly. No one knows build 12 or date 1234 means mc 1.17).