Looking into SpongePowered/SpongeForge#2367, I have a proposal to update the versioning scheme so that api for 1.15 and 1.14 can be released altogether.

version = Globals.mcVersion + "-" + Globals.baseVersion + "+" + (ENV.BUILD_NUMBER ? ("build." + ENV.BUILD_NUMBER) : "local")

So as to reduce confusions for the different Minecraft versions.

Yes, your approach (@liach) seems good and would perfectly comply with SemVer.
What's more of a problem currently tho, is that the modules use git hashes for build numbers / aren't always updated when there has been a mapping change but no code change (= difference in the built jar).

I think having he Minecraft version right at the beginning makes the most sense, as that would also allow versioning against that (ex: depends on fabric API 1.14 would mean it would depend on ANY fabric API jar built for Minecraft 1.14)

@sfPlayer1 suggests this versioning scheme (mcversion in the end)

version = Globals.baseVersion + "+" + (ENV.BUILD_NUMBER ? ("build." + ENV.BUILD_NUMBER) : "local") + "+" +  Globals.mcVersion

So as to reduce confusions for the different Minecraft versions.

A Minecraft version prefix is not at all semver compatible, see the grammar at https://semver.org/ and the implications from mc not using semver itself. Fabric Loader infers a generally compliant and monotonous version, but it's not too understandable for every end user looking at the api jar from CF.

The suffix is just informational, there's no need to process the API version. We now expose a minecraft dummy mod with a comparable and dependable version. A MC version prefix doesn't solve module ordering since there may be disjoint feature progression and they are likely to cover multiple MC versions.

We're adding the git branch as an addition to the build number, which both covers the build number's namespace and generally convey the MC version (for end users).