Files
gh-christianlouis-docuelevate/docs/ReleaseNaming.md
T
copilot-swe-agent[bot] d18c10996a feat(release): add named release anchors with codenames and roadmap integration
- Add release_names.json mapping version ranges to codenames
- Add release_name property to Settings in app/config.py
- Update build metadata script to include codename in RUNTIME_INFO
- Display release codename in status dashboard and page footer
- Inject release_name globally via template response wrapper
- Update ROADMAP.md with codenames for all milestone releases
- Add docs/ReleaseNaming.md with naming guide and best practices
- Add comprehensive tests for release name resolution

Co-authored-by: christianlouis <361235+christianlouis@users.noreply.github.com>
2026-03-01 18:32:46 +00:00

5.4 KiB

Release Naming Guide

DocuElevate uses automated semantic versioning via python-semantic-release combined with named release anchors (codenames) for milestone releases. This guide explains how the two systems work together.

How It Works

Automated Versioning (Patch & Minor Releases)

Every merge to main is analyzed by python-semantic-release:

  • feat: commits → minor version bump (e.g., 0.5.0 → 0.6.0)
  • fix: / perf: commits → patch version bump (e.g., 0.5.0 → 0.5.1)
  • docs: / chore: / etc. → no version bump

This happens automatically — no manual intervention needed.

Named Release Anchors (Codenames)

Major milestone releases carry a codename that anchors the release in project history. Codenames:

  • Are defined in release_names.json at the project root
  • Map to minor version ranges (e.g., all 0.5.x releases share the codename "Foundation")
  • Appear in the status dashboard, build metadata, and footer
  • Do not interfere with automatic version numbering

Current Release Names

Version Range Codename Description
0.5.x Foundation Core platform with multi-provider storage, AI, and UI
0.6.x Clarity Enhanced search, filtering, and improved UI/UX
0.7.x Conductor Workflow automation, custom pipelines, rule-based logic
1.0.x Summit Enterprise-ready: multi-tenancy, RBAC, horizontal scaling
1.1.x Bridge Collaboration features, document sharing, analytics
2.0.x Horizon On-premise AI, advanced management, platform expansion

Adding a New Release Name

  1. Edit release_names.json at the project root:
{
  "releases": {
    "0.8": {
      "codename": "YourCodename",
      "description": "Short description of what this release series focuses on",
      "milestone": "v0.8.0 - Your Milestone Name"
    }
  }
}
  1. Update ROADMAP.md to include the codename in the appropriate milestone section.

  2. Update this documentation to add the new entry to the table above.

The codename will automatically appear in:

  • The application footer (all pages)
  • The status dashboard (/status)
  • Build metadata (RUNTIME_INFO file)

How the Lookup Works

The application resolves codenames using a cascading lookup against the current version:

  1. Exact match: Checks if the full version (e.g., 0.5.3) has an entry
  2. Minor prefix: Checks the minor version prefix (e.g., 0.5)
  3. Major prefix: Checks the major version prefix (e.g., 0)

This means all patch releases within a minor version series inherit the same codename.

Codename Naming Conventions

When choosing codenames, follow these guidelines:

  • Use single, evocative words that relate to the release's theme
  • Keep names professional — they appear in user-facing UI
  • Pick names that hint at the milestone's focus (e.g., "Foundation" for core platform, "Conductor" for workflow automation)
  • Avoid names that could become dated or reference external products
  • Ensure uniqueness — no two releases should share a codename

Integration with Milestones

Each codename maps to a GitHub milestone. The milestone field in release_names.json matches the milestone title used for issue tracking:

v0.7.0 - Workflow Automation  →  codename: "Conductor"
v1.0.0 - Enterprise           →  codename: "Summit"

This creates a clear link between planning (milestones), delivery (releases), and communication (codenames).

Best Practices: Blending Automated and Named Releases

Do

  • Let semantic-release handle all version numbering automatically
  • Use codenames for milestone releases (minor/major versions), not every patch
  • Reference codenames in release notes and changelogs for major versions
  • Keep release_names.json in sync with ROADMAP.md
  • Announce codenames in GitHub Release descriptions for milestone versions

Don't

  • Manually edit the VERSION file — it's managed by semantic-release
  • Create codenames for every patch release (0.5.1, 0.5.2, etc.)
  • Use codenames that conflict with version numbers
  • Skip updating release_names.json when adding a new milestone to the roadmap

Where Codenames Appear

Location Format
Status dashboard App Version: 0.5.3 "Foundation"
Page footer Version 0.5.3 "Foundation"
RUNTIME_INFO metadata Release Name: Foundation
ROADMAP.md Section headers include codenames

File Reference

File Purpose
release_names.json Source of truth for version-to-codename map
app/config.py release_name property reads the JSON
scripts/generate_build_metadata.sh Includes codename in RUNTIME_INFO
app/views/base.py Injects release_name into all templates
ROADMAP.md Displays codenames alongside milestones