| name | versioning |
| description | Versioning strategy and Semantic Versioning guide for Chrono Dawn mod |
Versioning Guide
Purpose: Document versioning strategy and provide guidance for version updates in Chrono Dawn mod.
When to use: When updating mod version, preparing for release, or understanding version numbering.
Semantic Versioning Overview
Chrono Dawn follows Semantic Versioning 2.0.0 (https://semver.org/).
Version Format
<major>.<minor>.<patch>-<prerelease>+<buildmetadata>
Examples:
0.2.0-beta+1.21.1-fabric- Beta version for Minecraft 1.21.1 (Fabric)1.0.0+1.21.1-neoforge- Stable release for Minecraft 1.21.1 (NeoForge)1.2.3-rc.1+1.21.2-fabric- Release Candidate 1 for Minecraft 1.21.2 (Fabric)
Components
Version Number (
major.minor.patch):major: Incompatible API changes (e.g., 0.x.x → 1.0.0)minor: New features, backward-compatible (e.g., 1.0.0 → 1.1.0)patch: Bug fixes, backward-compatible (e.g., 1.1.0 → 1.1.1)
Prerelease Identifier (optional,
-<identifier>):- Separated by hyphen
- - Examples:
-alpha,-beta,-rc.1 - Indicates unstable/pre-release version
- Removed for stable releases
- Separated by hyphen
Build Metadata (
+<minecraft-version>-<loader>):- Separated by plus
+ - Format:
+<minecraft_version>-<fabric|neoforge> - Example:
+1.21.1-fabric - Automatically appended by build system
- Separated by plus
Chrono Dawn Versioning Strategy
Development vs. Release Versions
Development (during feature implementation):
mod_version=0.2.0-beta
Builds to: chronodawn-0.2.0-beta+1.21.1-fabric.jar
Release (when publishing):
mod_version=0.2.0
Builds to: chronodawn-0.2.0+1.21.1-fabric.jar
Prerelease Identifiers
Use appropriate identifiers based on development stage:
-alpha: Early development, major features incomplete- Example:
0.2.0-alpha - Use case: Initial implementation of new dimension
- Example:
-beta: Feature-complete, testing in progress- Example:
0.2.0-beta - Use case: All bosses implemented, playtesting phase
- Example:
-rc.1,-rc.2, etc.: Release Candidate- Example:
1.0.0-rc.1 - Use case: Final testing before stable release, no new features
- Example:
No identifier: Stable release
- Example:
1.0.0 - Use case: Production-ready, fully tested
- Example:
Version Increment Guide
| Change Type | Example | When to Use |
|---|---|---|
0.1.0 → 0.2.0 |
New major features (new dimension area, new boss system) | |
0.2.0 → 0.2.1 |
Bug fixes only | |
0.9.0 → 1.0.0 |
First stable release | |
1.0.0 → 2.0.0 |
Breaking changes (incompatible with old saves) |
Build System Integration
gradle.properties
Define only the version number and prerelease identifier:
mod_version=0.2.0-beta
Do NOT include Minecraft version or loader name here.
Build Scripts
fabric/build.gradle (line 86):
archiveVersion = "${rootProject.mod_version}+${rootProject.minecraft_version}-fabric"
neoforge/build.gradle (line 98):
archiveVersion = "${rootProject.mod_version}+${rootProject.minecraft_version}-neoforge"
These scripts automatically append +1.21.1-fabric or +1.21.1-neoforge.
Resulting JAR Names
From mod_version=0.2.0-beta:
- Fabric:
chronodawn-0.2.0-beta+1.21.1-fabric.jar - NeoForge:
chronodawn-0.2.0-beta+1.21.1-neoforge.jar - Common:
common-0.2.0-beta.jar
Version Update Procedure
Files to Update
When changing mod_version in gradle.properties, also update:
gradle.properties (line 6)
mod_version=X.Y.Z-prereleaseREADME.md (lines 81-83, 209, 220)
- Build output file names
- Installation instructions
docs/player_guide.md (lines 78-79)
- Download file names
docs/developer_guide.md (lines 235, 274-276)
- gradle.properties example
- Build output file names
fabric.mod.json and neoforge.mods.toml
- Use
${version}placeholder (no manual update needed)
- Use
Version Update Checklist
- Update
gradle.propertieswith new version - Update all documentation with correct JAR names (include
+1.21.1) - Verify version format follows Semantic Versioning
- For release: Remove prerelease identifier (e.g.,
-beta) - Test build:
./gradlew clean build - Verify JAR names match documentation
Common Patterns
Preparing Next Version (Development)
# Start development on 0.3.0
mod_version=0.3.0-alpha
Pre-Release Testing
# Feature-complete, ready for testing
mod_version=0.3.0-beta
Release Candidate
# Final testing before release
mod_version=0.3.0-rc.1
Stable Release
# Production release
mod_version=0.3.0
Hotfix Release
# Critical bug fix for 0.3.0
mod_version=0.3.1
Examples by Scenario
Scenario 1: Starting Development on 0.2.0
Current: 0.1.0 (stable)
Change to: 0.2.0-alpha
Reason: Beginning work on new features
Scenario 2: Entering Beta Phase
Current: 0.2.0-alpha
Change to: 0.2.0-beta
Reason: All features implemented, testing phase
Scenario 3: Preparing Release
Current: 0.2.0-beta
Change to: 0.2.0-rc.1
Reason: Final testing before release
Scenario 4: Stable Release
Current: 0.2.0-rc.1
Change to: 0.2.0
Reason: Release candidate passed testing
Scenario 5: Bug Fix Release
Current: 0.2.0 (stable)
Change to: 0.2.1
Reason: Critical bug found, needs hotfix
Automated Version Update
Use the update-version command to automate version updates:
/update-version 0.3.0-beta
This will:
- Update
gradle.properties - Update all documentation files with correct JAR names
- Verify version format
Reference
- Semantic Versioning Spec: https://semver.org/
- Current Version: Check
gradle.propertiesline 6 - Version History: See git tags and CHANGELOG.md (if exists)
Last Updated: 2026-01-01 Maintained by: Chrono Dawn Development Team