[Organization] Semantic Versioning 2.0.0 (SemVer) Compliance

[carrierpigeondev]

Intro

Since Tale of Biomes is currently in an early development phase, now would be the best time to ensure that the project implements and maintains proper Semantic Versioning 2.0.0 (aka. SemVer) compliance.

Why?

See the "Why Use Semantic Versioning?" section of the website for details on specifically why to use SemVer over some other versioning standard (or any standard at all). However, this project also has inconsistencies in its own versioning.

For example, with the newest release:

• The release title is Snapshot 0.8.0-Indev
• The release tag on GitHub is r-indev-0.8.0, whereas the previous release tag was r0.7.0-indev
• The build is referred to as v0.8.0-indev in the description
• The JAR file is Tale_of_Biomes-Indev-0.8.0-NeoForge-1.20.4.jar
• The mod version in MCreator (in the Workspace settings) is 0.8.0

How to fix this

In future versions (e.g. 0.9.0), the following changes can be made:

The mod version in MCreator should be changed to 0.9.0-indev

This complies with SemVer as it has the major.minor.patch format and includes the pre-release (i.e. indev) information separated by a hyphen after the version information.

The JAR file should be changed to Tale-of-Biomes_0.9.0-indev+NeoForge-1.20.4

This includes the SemVer compliant 0.9.0-indev version, and includes the name of the mod (Tale of Biomes) separated from the version information with an underscore. This also includes build metadata (i.e. the modloader and MC version) separated by a plus sign after the pre-release information.

The build should be referred to as 0.9.0-indev

This mirrors the internal name of the version.

The release tag on GitHub should be v0.9.0-indev

See the included snippet from the SemVer website below:

Is “v1.2.3” a semantic version?

No, “v1.2.3” is not a semantic version. However, prefixing a semantic version with a “v” is a common way (in English) to indicate it is a version number. Abbreviating “version” as “v” is often seen with version control. Example: git tag v1.2.3 -m "Release version 1.2.3", in which case “v1.2.3” is a tag name and the semantic version is “1.2.3”.

The release title should be 0.9.0-indev (Snapshot)

This includes the SemVer compliant 0.9.0-indev version, while also including the information that it is a Snapshot release (also, Snapshot may not be the proper term in this case. Snapshot, at least in Minecraft, is used to refer to a development version before a Pre-Release, which precedes a Release Candidate, which precedes a release, not an indev build. This doesn't really have anything to do with SemVer though.)

Additional

I've also noticed that the mod, titled Tale of Biomes is referred to as Tale Of Biomes (where the O is capitalized) in a couple contexts. Specifically:

• The MCreator Workspace...
• The Tale Of Biomes: After Five Months video on the "NorthWestTrees MCreator" YouTube channel.

Just something to look out for ;)

In addition to the previous information on SemVers, I feel that it may be too ambitious to have complete compliance with SemVer, as it also includes the following requirements:

Patch version Z (x.y.Z | x > 0) MUST be incremented if only backward compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior.

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backward compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.

Major version X (X.y.z | X > 0) MUST be incremented if any backward incompatible changes are introduced to the public API. It MAY also include minor and patch level changes. Patch and minor versions MUST be reset to 0 when major version is incremented.

These may be a bit extreme for a Minecraft mod where practically every version is backwards incompatible.

Conclusion

Overall, not only will these proposed changes implement compliance for a widely recognized versioning standard, but also make the versioning more consistent across the entire project.

[northwesttreesgaming]

The only thing I am not sure about is the forge update JSON file because the MCreator version links to that config file which may be required to be just the m.m.p numbers. I have never tried it without just the numbers but I worry that it will mess with the JSON file if I am not careful with the data I use in there. Other than that I have corrected the tags and titles for the releases. I still need to update the build information on each page, and updating the tags has caused the order of the tags to put v0.5.0 at the bottom of the list. But not much for it as that tag was made prior and far as I know Github has now way to structure it back to normal.

[carrierpigeondev]

Ah, that is a good point about update.json.

I did a bit of research but couldn't find many good examples of other projects that use the Forge Update Checker. I only found one, Sound Physics Remastered, which used the hyphen as a separator between the Minecraft version and the mod version (i.e. 1.20.4-1.3.0).

Their update.json is here: https://update.maxhenkel.de/forge/sound_physics_remastered

However, it seems that MCreator removes hyphens and non-integer characters. For example, I cloned the repo just to have a project already set up with the Forge Update Checker. I changed the mod version in the Workspace settings to 0.9.0-1.20.6-indev and it appeared as 0.9.01.20.6 in Minecraft (specifically the mod menu). Not sure how this could be changed either, as MCreator automatically changes the value on build, even if mods.toml is changed.