&ND v2

+++document/meta
schemaVersion = "1"
id = "aeon-v1-release-governance"
title = "AEON v1 Release Governance"
description = "Governance policy for AEON v1 releases, changelog rules, version claims, and how conformance claims relate to released artifacts."
family = "aeon"
group = "Core Specifications"
standing = "official"
lifecycle = "published"
normativity = "normative"
license = "CC-BY-4.0"
path = "specification/aeon-v1-documentation/aeon-v1-release-governance"
order = 90
publish = true
keywords = ["AEON", "release governance", "versioning", "tags", "branches", "conformance claims"]
related = ["aeon-core-v1", "aeon-core-v1-compliance", "aeon-v1-conformance-matrix", "aeon-v1-official-index", "aeon-v1-contracts"]
+++


# AEON v1 Release Governance [# aeon-v1-release-governance]

Scope: release tags, branching, changelog/migration rules, and conformance-claim format for AEON v1.


## 1. Purpose [# purpose]

This document defines how AEON v1 releases are cut, identified, and claimed.

It exists to keep four things stable:

- immutable public release history
- unambiguous spec-to-implementation mapping
- clear migration signaling
- version-scoped conformance claims


## 2. Release Units [# release-units]

AEON release governance tracks three related but distinct release units:

1. specification line
  - example: [$ AEON v1]
  - governs normative language behavior and contracts

2. contract artifacts
  - examples:
    - [$ aeon.gp.profile.v1]
    - [$ aeon.gp.schema.v1]
  - governed by contract-layer identifiers and contract artifact versions

3. implementation packages
  - examples:
    - [$ @aeon/core]
    - [$ @aeon/cli]
    - [$ @aeon/aeos]
  - governed by package semver

Patch or implementation fixes do not change the specification-line identity unless normative behavior changes.


### 2.1 Locked Layer Naming [# locked-layer-naming]

Specification line:

- [$ AEON v1]

Code-layer release labels:

- [$ AEON.core v1.0.0]
- [$ AEON.schema v1.0.0]
- [$ AEON.gp.tonic v1.0.0]

Contract-layer identifiers:

- [$ aeon.gp.profile.v1]
- [$ aeon.gp.schema.v1]


## 3. Tag Strategy [# tag-strategy]

Release tags MUST be immutable.

Required rules:

- use annotated git tags for public releases
- never retag an existing released version
- if a release is bad, publish a new version; do not move the old tag

Recommended tag forms:

- spec baseline tags:
  - [$ spec/v1.0.0]
  - [$ spec/v1.0.1]

- repository release tags:
  - [$ release/v1.0.0]
  - [$ release/v1.0.1]

Practical rule:

- [$ spec/*] identifies the normative documentation/contracts baseline
- [$ release/*] identifies the repository snapshot that ships that baseline

If only one tag family is maintained, use [$ release/vX.Y.Z] and ensure the release notes explicitly name the matching
spec baseline.


## 4. Branch Strategy [# branch-strategy]

AEON uses a simple trunk-plus-release-branch model.

Branches:

- [$ main]
  - integration branch for the next unreleased change set

- [$ release/v1]
  - stabilization branch for the active v1 release line

- short-lived topic branches
  - recommended prefix: [$ codex/] or contributor-specific topic names

Rules:

- feature work lands in topic branches, then merges into [$ main]
- once release hardening begins for v1, cut [$ release/v1] from [$ main]
- patch releases for v1 are cut from [$ release/v1]
- [$ main] may continue with future work after the release branch is cut
- fixes needed in both places should land in [$ release/v1] and be forward-merged to [$ main], or land in [$ main] and
  be cherry-picked with explicit tracking

Non-goal:

- no long-lived archive branches per historical release

Immutable tags are the archive.


## 5. Release Process [# release-process]

Minimum release process for a public AEON v1 release:

1. freeze target scope
  - accepted proposals for the release must already be reflected in:
    - canonical docs
    - CTS
    - shipped implementation behavior

2. run release gate
  - run required test and CTS commands for the target implementation set
  - run canonical CTS lane ([$ bash ./scripts/canonical-cts.sh --mode all --brief])
  - confirm contract artifacts and registry hashes are current

3. update release metadata
  - changelog entry
  - release notes summary
  - conformance claim statement

4. cut tag
  - create immutable annotated release tag

5. publish artifacts
  - source snapshot
  - contract artifacts
  - package artifacts if applicable


## 6. Changelog and Migration Requirements [# changelog-and-migration-requirements]

Every public release MUST include a changelog entry.

Changelog sections:

- Added
- Changed
- Fixed
- Removed
- Spec Impact
- CTS Impact

Migration notes are REQUIRED when any of the following occur:

- normative behavior changes
- diagnostics relied on by CTS/users change
- contract document shape changes
- CLI/runtime flags change
- canonical examples or accepted syntax forms change

If no migration action is required, state:

- [$ Migration: none]


## 7. Conformance Claim Format [# conformance-claim-format]

Conformance claims MUST be explicit about:

- implementation identity
- implementation version
- specification line
- CTS protocol version
- lanes executed
- result date

Recommended format:

~~~$ text
Implementation: @aeon/cli 1.0.0
Claims: AEON Core v1.0.0, AEOS v1.0.0
CTS Protocol: cts.protocol.v1
CTS Lanes:
- cts/core/v1
- cts/aes/v1
- cts/annotations/v1
- cts/aeos/v1
Result: pass
Date: 2026-03-06
~~~$

Rules:

- claims are version-scoped
- passing one lane does not imply passing all lanes
- a package may claim only the layers/lane coverage it actually passed
- contract IDs and implementation package versions must not be conflated


## 8. Archive Policy [# archive-policy]

AEON does not require a separate archive repository.

Policy:

- immutable git tags and release artifacts are the archive
- old release lines remain available through tags/releases
- superseded docs may remain in-repo as historical material if clearly labeled, but active conformance claims point only
  to the canonical v1 surface


## 9. Branching Model Publication [# branching-model-publication]

This document is the published branching model for AEON v1.

It supersedes the earlier planning target:

- [$ setup/branching-release-model.md]

The branching model is intentionally kept inside the versioned spec/governance surface so release policy evolves
alongside the language and CTS.