Skip to content

specification.md

Latest commit

 

History

History
64 lines (44 loc) · 3.98 KB

specification.md

File metadata and controls

64 lines (44 loc) · 3.98 KB
Raw

JLDN Generational Versioning Schema Specification

Document: docs/specification.md
Author: Jeff Langdon (JL Design Network)
Ruleset / Schema: JLDN Generational Versioning Format
Version: 2607.2.0-s

This document defines the official specification for the JLDN Generational Versioning Schema (GVS). Designed as a proprietary, generational standard, this schema combines architectural historical context, feature iteration, and precise lifecycle and support tracking into a single, chronologically sortable string.

1. The Format Structure

The strict format for all releases is defined as follows:

[YYMM].[SUBVERSION].[REVISION]-[TAG]

Each position within the schema serves a distinct architectural purpose:

  • [YYMM] (The Epoch): A four-digit generational marker representing the two-digit year and two-digit zero-padded month when the core architecture of the software was born (e.g., 2607 for July 2026). This does not act as a rolling calendar; it only updates when a fundamentally new architecture or major rewrite is initiated.
  • [SUBVERSION]: An incrementing integer tracking backward-compatible feature additions, architectural expansions, or significant UI changes within the current generation.
  • [REVISION]: An incrementing integer tracking bug fixes, security patches, and minor code adjustments that do not introduce new functionality.
  • -[TAG]: A compound string representing both the software's current position in the development lifecycle and its official support status.

2. Compound Lifecycle Tags

The tag system utilizes a base Greek-inspired phase identifier combined with an optional s modifier to indicate active external support. This specific lettering ensures perfect native alphabetical sorting across the software's lifespan.

Phase Tag Meaning & Support Status
Alpha (Internal) -a Genesis Build: The first testable build, kept strictly in-house. No external support.
Alpha (Public) -as Genesis Build: Released for early external/live testing. Actively supported.
Beta (Internal) -b Crucible Build: Feature complete, focused on bug hunting, but kept in-house. No external support.
Beta (Public) -bs Crucible Build: Released for wider real-world testing. Supported.
Lambda -l The Lock (RC): Release Candidate. Code freeze active. Under review, no support yet.
Stable -s Production: The official, stable production release. Fully supported.
Theta -ts Twilight: Deprecation warning. Users are encouraged to migrate, but the version is still supported.
Zeta -z Zero-Hour (EOL): End of Life. The final update the software will ever receive. Completely unsupported.

3. Validation Regular Expression

To ensure data integrity across CI/CD pipelines, ingestion engines, and automated systems, all version strings must strictly pass the following regular expression:

^(\d{2}(?:0[1-9]|1[0-2]))\.(\d+)\.(\d+)-(a|as|b|bs|l|s|ts|z)$
  • ^ ... $: Enforces exact matching to prevent trailing or leading invalid characters.
  • (\d{2}(?:0[1-9]|1[0-2])): Captures the Epoch generation, forcing the month to be a valid zero-padded number between 01 and 12.
  • (\d+): Captures the subversion and revision as unbounded integers.
  • -(a|as|b|bs|l|s|ts|z): Strictly matches the approved compound tags, accounting for both supported and unsupported Alpha/Beta builds.

4. Subversion Milestones vs. Revision Bumps

  • Subversion Milestones ([YYMM].[SUBVERSION].0-[TAG]): Triggered on new features, rule mechanics, or architectural expansions. Requires an annotated Git tag AND a formal published GitHub/GitLab release.
  • Revision Bumps ([YYMM].[SUBVERSION].[REVISION]-[TAG] where REVISION > 0): Triggered on minor bug fixes, typo corrections, or formatting tweaks. Requires an annotated Git tag ONLY (no public release published).