This document describes the versioning strategy I use for my Minecraft mods, based on Forge and NeoForge.
Each release is tagged as:
<MC_VERSION>-<MOD_VERSION>
Example: 1.21.3-4.2.0.7
- MC_VERSION: The Minecraft version.
- MOD_VERSION: A four-part number:
Major.Minor.Feature.Patch
.
Filename structure:
<modname>-<loader>-<MC_VERSION>-<MOD_VERSION>.jar
Example: bucketlib-fabric-1.21.3-4.2.0.7.jar
-
Major (first number):
- Increased for Minecraft major/minor updates (e.g., 1→2 or 21→22).
- Complete mod rewrites
- Resets Minor, Feature, and Patch to
0
.
-
Minor (second number):
- Increased for Minecraft patch updates (e.g., 1.21.3→1.21.4) or Loader changes.
- Breaking changes or large mod changes.
- Resets Feature and Patch to
0
.
-
Feature (third number):
- Increased for added, removed, or reworked features without breaking changes.
- Resets Patch to
0
.
-
Patch (fourth number):
- Increased for bugfixes or small improvements.
Whenever a higher version part increases, all lower parts are reset to 0
.
Example transitions:
- Bugfix →
1.21.3-4.2.0.8
- New feature →
1.21.3-4.2.1.0
- Minecraft patch update →
1.21.4-4.3.0.0
- Minecraft minor update →
1.22-5.0.0.0
Pre-releases:
-alphaX
: Early development.-betaX
: Feature-complete, unstable.-rcX
: Release candidate.
Example: 1.21.3-4.2.0.7-beta1
Each release builds for multiple loaders (Fabric, Forge, NeoForge).
The loader is listed in the filename, not in the Git tag.
Examples:
bucketlib-fabric-1.21.3-4.2.0.7.jar
bucketlib-forge-1.21.3-4.2.0.7.jar
bucketlib-neoforge-1.21.3-4.2.0.7.jar
For currently supported Minecraft versions, see:
➡️ Supported Versions
This versioning system ensures clarity, compatibility, and easy automation across releases.