First some background, SpongeForge is a Minecraft Modding Platform (read as, consumed by kids and teenagers) that Also has a corresponding API Sponge API , we call mods made for SpongeAPI plugins.
Sponge API is currently at major version 7. Our snapshot API release for our stable branch, is currently 7.1.0-SNAPSHOT
We come across the issue, that we want to be able to change (non backwards compatible) changes to the API until the new features are released for 7.1 (to follow semver, we must not break ABI without a major version change)
But still provide a preview to plugin developers (Also usually kids and teens) to test and use the new API.
We have limited resources, so what usually happens is that.
API 7 is released.
API is bumped to API7.1-SNAPSHOT
So SpongeForge maybe has 1 single build that’s built against API7.0.0 before moving on to API7.1.0-SNAPSHOT.
For simplicities sake, we would like to build SpongeForge against 7.1.0-SNAPSHOT to continue to provide API previews for the next version to plugin developers, with the knowing risk that they should not release their plugins against it until the API is released, if they want ABI to be guarantee’d until the next Major release.
This brings us to versioning.
Minecraft Server Owners are usually uneducated kids, (compared to plugin devs, which tend to be slightly educated teens and hobbyists in college)
At current our aretfacts are named like ( example here https://www.spongepowered.org/downloads/spongeforge/stable/1.12.2)
Which represents the MinecraftVersion-ForgeVersion-APIVersion-???-build
Which badly represents the current state of SpongeForge.
This version of SpongeForge has been built against a 7.1.0 snapshot API, but only the 7.0.0 API is released / guarantee’d to not change.
The MinecraftVersion is for simplicity, so kids can easily recognize which version they need.
The Forge Version is a build number of Minecraft Forge, (which we perform bytecode transformation on) so roughly needs to match in order to not have compatibility issues.
How can we name our artifacts / versions, so that the API version in the artifact string, is the last released version of the API, whilst still building against the preview API? Allowing us to have our cake and eat it in regards to letting devs play with a live preview of upcoming API, and correctly advertising the current version that users should care about?
The reason this comes up now, is we want to simplify our names and versioning, so that users would see
(A recommended build is the closest thing we have to a ‘release’, it’s essentially perpetually experimental software)
If you are worried about the next major snapshot API version, those downloads are kept separate under Experimental on the downloads page, and should indicate that they are snapshots, and of which Major API version they are snapshots of.