Files
acdl/docs/pipeline/versioning.md
T
Jon Chery 0d2cbdb423 feat(P1): remove gitea/gitlab from synced files + simplify docs (REQ-230,231,232)
Genericize forge-detection code: gitea→forge/generic_forge, GITEA_ACTOR→FORGE_ACTOR.
Drop .gitea byte-identity test assertions (keep GitHub-side + contract conformance).
Add test_no_forge_mentions.py guard test (REQ-230).
Delete completed migration docs (NOVA_MIGRATION.md, NOVA_AWS_MIGRATION.md).
Move NO_HUMANS_THESIS.md to .ciagent/ (internal artifact).
Strip ciagent-internal provenance from synced docs (REQ-/D-/P-/CAP- IDs,
milestone headers, .ciagent/PROJECT.md citations).
Trim README.md (reusable deploy section, local key rotation paragraph).
Fix version-tag drift (@v1.13→@v1.19, acdl/→nova/).

---ci---
project: acdl
phase: 1
milestone: v1.20
status: execute
requirements: [REQ-230, REQ-231, REQ-232]
---/ci---
2026-08-07 18:20:29 +00:00

2.3 KiB

Versioning

Nova uses two versioning schemes: one for modules, one for the deploy pipeline. Both matter to a consumer.

Module versioning

Primitives and modules use semver with three triggers:

  • interface → MAJOR — a breaking change to the module's inputs/outputs.
  • behavior → MINOR — a backward-compatible behavior change.
  • lifecycle → PATCH — a fix or internal change.

A MAJOR bump requires a new registry entry (immutable publication); the old entry enters a 12-month deprecation window. A module pins its primitives by name@semver; the resolver picks the highest compatible.

Module versions are tracked in registry.json.

Deploy-pipeline versioning (the CI workflow uses: tag)

The central deploy pipeline is referenced by a floating MAJOR + MINOR tag in a consumer's CI workflow definition:

jobs:
  deploy:
    uses: nova/.github/workflows/deploy.yml@v1.19
    with:
      contract: .nova/contract.yml

The version pin lives in the CI workflow reference (not in the contract itself — the contract no longer carries a uses: field). The CI workflow uses: tag is the only immutability lever a consumer has.

Unversioned references are discouraged. Do not use @main or a bare nova/.github/workflows/deploy.ymlmain is constantly updated and can cause unexpected failures. Pinning to a MAJOR+MINOR tag means:

  • Immutability — the pipeline behavior you tested is the behavior you get. Patch fixes flow within the tag; breaking changes land under the next MINOR tag (@v1.5), which you opt into explicitly.
  • Resilience — your deployment does not break because an unrelated change landed on main.
  • Reproducibility — your setup is stable. You upgrade on your schedule by bumping the tag.

When a new tag is released

When a new MINOR tag is released (e.g. @v1.5), review its changelog and bump your uses: reference when ready. The old tag continues to receive patch fixes until the next MINOR tag.

Production-bound references

For production-bound workflows, the platform resolves the current tag to its SHA (tag for dev/qa, SHA for prod). This prevents a silent patch from changing a production deployment. The platform provides a CLI command for the tag → SHA resolution.