Agent skill

versioning

Versioning strategy and Semantic Versioning guide

Stars 163
Forks 31

Install this agent skill to your Project

npx add-skill https://github.com/majiayu000/claude-skill-registry/tree/main/skills/other/versioning-majiayu000-claude-skill-registr

SKILL.md

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

  1. 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)
  2. Prerelease Identifier (optional, -<identifier>):

    • Separated by hyphen -
    • Examples: -alpha, -beta, -rc.1
    • Indicates unstable/pre-release version
    • Removed for stable releases
  3. Build Metadata (+<minecraft-version>-<loader>):

    • Separated by plus +
    • Format: +<minecraft_version>-<fabric|neoforge>
    • Example: +1.21.1-fabric
    • Automatically appended by build system

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
  • -beta: Feature-complete, testing in progress

    • Example: 0.2.0-beta
    • Use case: All bosses implemented, playtesting phase
  • -rc.1, -rc.2, etc.: Release Candidate

    • Example: 1.0.0-rc.1
    • Use case: Final testing before stable release, no new features
  • No identifier: Stable release

    • Example: 1.0.0
    • Use case: Production-ready, fully tested

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:

properties
mod_version=0.2.0-beta

Do NOT include Minecraft version or loader name here.

Build Scripts

fabric/build.gradle (line 86):

groovy
archiveVersion = "${rootProject.mod_version}+${rootProject.minecraft_version}-fabric"

neoforge/build.gradle (line 98):

groovy
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:

  1. gradle.properties (line 6)

    properties
    mod_version=X.Y.Z-prerelease
    
  2. README.md (lines 81-83, 209, 220)

    • Build output file names
    • Installation instructions
  3. docs/player_guide.md (lines 78-79)

    • Download file names
  4. docs/developer_guide.md (lines 235, 274-276)

    • gradle.properties example
    • Build output file names
  5. fabric.mod.json and neoforge.mods.toml

    • Use ${version} placeholder (no manual update needed)

Version Update Checklist

  • Update gradle.properties with 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)

bash
# Start development on 0.3.0
mod_version=0.3.0-alpha

Pre-Release Testing

bash
# Feature-complete, ready for testing
mod_version=0.3.0-beta

Release Candidate

bash
# Final testing before release
mod_version=0.3.0-rc.1

Stable Release

bash
# Production release
mod_version=0.3.0

Hotfix Release

bash
# 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:

bash
/update-version 0.3.0-beta

This will:

  1. Update gradle.properties
  2. Update all documentation files with correct JAR names
  3. Verify version format

Reference

  • Semantic Versioning Spec: https://semver.org/
  • Current Version: Check gradle.properties line 6
  • Version History: See git tags and CHANGELOG.md (if exists)

Last Updated: 2026-01-01 Maintained by: Chrono Dawn Development Team

Expand your agent's capabilities with these related and highly-rated skills.

Didn't find tool you were looking for?

Be as detailed as possible for better results