📄

published document version nebula-storm-2026.0820.1.2-r craftedlogic.net ltd (reg no. 04056778)

craftedlogic-calver

(craftedlogic calendar versioning)

Overview

Craftedlogic Calendar Versioning (named 'craftedlogic-calver') is a calendar-based versioning scheme that combines semantic meaning with calendar dates and release iteration tracking.

Format Specification

<OPTIONAL_PRODUCT_NAME> <RELEASE_NAME> YYYY.MMDD.<INCREMENT>-<MODIFIER>

Components

Version Examples

Modifier Definitions

0-Alpha (a)

• Status: Pre-release, feature development ongoing
• Stability: Unstable; features may change or be removed
• Use Case: Early development, closed testing, experimental features
• User Base: Developers, testers willing to work with breaking changes

1-Beta (b)

• Status: Pre-release, feature-complete
• Stability: Mostly stable; core functionality locked, bugs being fixed
• Use Case: Community testing, feedback collection, final refinements
• User Base: Early adopters, quality testers

2-Release (r)

• Status: Production-ready, stable
• Stability: Fully stable; all features finalized and tested
• Use Case: Official published release
• User Base: All users

"Build" vs "Release"

References to 'Release' version is only used to refer to the stable production ready feature published release. Whereas Alpha(a) and Beta(b) are just 'build' versions in stages of test. The build/patch/increment number is used for all versions.

Rules & Guidelines

Release Names

• Two-word pairs only (no more, no fewer)
• Thematic consistency encouraged (e.g., weather-related, celestial bodies, elements etc.)
• Alpha characters and hyphens allowed but numbers are not
• Examples: Aurora Dawn, Crystal Shield, Phoenix Rise, Velvet Ember

Date Component

• Release versions are YYYY.MMDD format (4-digit year, 2-digit month, 2-digit day)
• Represents the intended or actual release date
• Invalid dates are not allowed (e.g., 2026.1332, 2026.0230 [Feb 30])

Increment Counter

• Starts at 0 for the first build of a given date-modifier combination
• Increments by 1 for each subsequent build for current release name
• Resets to 0 when moving to a new date but not when modifier changes
• Examples:
  • blueberry-pie-2026.0817.0.0-alpha → blueberry-pie-2026.0817.1.0-alpha → blueberry-pie-2026.0817.2.0-alpha
  • blueberry-pie-2026.0817.2.0-alpha → blueberry-pie-2026.0819.3.1-beta (new modifier, not reset to 0, 3rd increment, beta version not released)

Modifier Format

• Long form (alpha, beta, release) recommended for official documentation
• Short form (a, b, r) acceptable for compact display or automated systems
• Use consistently within a single project context
• Never mix forms in the same version string

Progression Rules

Standard Progression Path

For a given release name X-Z, versions progress as follows:

• X-Z-YYYY.MMDD.0.0-alpha (initial build)
• X-Z-YYYY.MMDD.1.0-alpha
• X-Z-YYYY.MMDD.2.0-alpha
• X-Z-YYYY.MMDD.3.1-beta
• X-Z-YYYY.MMDD.4.1-beta
• X-Z-YYYY.MMDD.5.2-release (first release, 5th build)
• X-Z-YYYY.MMDD.8.2-release (second release, 8th build)

Revision Increments

Revision to a version increment the <INCREMENT> counter:

• X-Z-YYYY.MMDD.5.2-release (original release)
• X-Z-YYYY.MMDD.6.0-alpha (sixth patch build)
• X-Z-YYYY.MMDD.7.2-beta (seventh patch build)
• X-Z-YYYY.MMDD.8.2-release (third release, 8th build)

New Build Dates

When a new build is compiled, the date is updated:

• X-Z.YYYY.MMDD.8.2-release (previous release)
• X-Z.YYYY.MMDD.9.0-alpha (new release, new date)

Filename Conventions

When using versions in filenames, the following rules apply:

Character Rules

• No spaces allowed in filenames
• Underscore (_) is the preferred separator for release names and components
• Dash (-) is acceptable and recommended for web-facing file links and URLs
• Release name spaces should be converted to underscores or dashes

Format Examples

With underscores (preferred for system files):

aurora_dawn_2026.0817.0.0-alpha.zip
crystal_shield_2026.0825.9.2-release.tar.gz
phoenix_rise_2026.0817.5.1-beta.exe

With dashes (preferred for web/URLs):

aurora-dawn-2026.0817.0-alpha.zip
crystal-shield-2026.0817.0-release.tar.gz
phoenix-rise-2026.0817.5-beta.exe

Usage Guidelines

• System/server files: Use underscores for better compatibility and readability
• Web links/URLs: Use dashes for cleaner, more readable URLs
• Version control tags: Use dashes or underscores consistently with your repository conventions
• Package managers: Follow the package manager's naming conventions (often dashes)

Invalid Filename Examples

Best Practices

1. Include release name in the feature iteration plan and in your changelog or releases page for clarity
2. Use consistent modifier form across your project (choose long or short, stick with it)
3. Include release notes that explain the date and stage (alpha/beta/release)
4. Tag releases in version control using the full version string
5. Communicate stability clearly in your documentation—users should know what alpha vs. beta means for your project
6. Use pre-release identifiers sparingly—don't spam alpha/beta builds unless testing is active
7. Choose underscore or dash globally and apply it consistently across all filenames

Invalid Examples

Implementation Notes

In version control tags: Use hyphens or underscores consistently:

		
		aurora_dawn_2026.0817.0.0-alpha
		aurora-dawn-2026.0817.0.0-alpha
		release/crystal-shield-2026.0817.0-release
		
	

In package manifests: Normalize spacing if needed:

	{
	  "name": "aurora-dawn",
	  "version": "2026.0817.0-alpha"
	}
	

For APIs/endpoints: Consider shorthand where appropriate:

/api/v2026.0817.0-a/

In download URLs:

		
			https://example.com/releases/craftedlogic-mars-xenon-orbit-2027.0217.4.2-r.zip
			https://example.com/downloads/craftedlogic-mars-silicon-dust-2027.0417.0-a.zip