Skip to content

Release cadence

When releases ship, how versions are assigned, and what triggers an RC vs a final tag.

Versioning scheme

TLSStress.Art follows Semantic Versioning 2.0.0 with this interpretation:

Bump When Examples
MAJOR (vX.0.0) Breaking change to a published surface — REST API, K8s manifest schema, OOBI canonical addressing, sealed-audit envelope, licence envelope, MÓDULO removal, Test Kind retirement v6.0.0 (mandatory Confidential Computing flip — planned), v5.0.0 (cloud-side scaffolds), v4.0.0 (DOM family)
MINOR (vX.Y.0) New feature, new MÓDULO, new Test Kind, new ZTP-prem camada, new patent-claim surface — without breaking existing ones v3.7.0 (ZTP-prem 12/12 closes), v3.6.0 (sustainability MVP), v3.5.0 (Phase 1 Materialization scaffolds)
PATCH (vX.Y.Z) Bug fixes, dependency bumps, doc improvements, hardening of existing surfaces v3.6.1 (release-feed auth fix), v3.5.2 (gitleaks workflow fix)

Pre-release tags use the -rc.N convention when we want signal from the field before the final tag.

Cadence — informal but predictable

The project is solo-maintained and noncommercial; we do not promise a calendar-driven release schedule. We do promise a signal-driven one:

Trigger Release type Typical lead time
New camada / MÓDULO / Test Kind ships Minor 1–4 weeks from feature freeze
Security advisory closes Patch (or back-portable patch on supported lines) within 5 business days of advisory acknowledgement (per SECURITY.md)
Critical bug discovered post-release Patch within 1–2 business days
Doc-only campaign closes Patch bundled with next routine patch
Major breaking change accepted via RFC Major 4–12 weeks from RFC accept, depending on scope

Historical pace (informational, not a commitment): patches every 1–2 weeks during active development, minors every 4–8 weeks.

RC (release candidate) flow

Used when the change is large enough to want field signal before the final tag. Always RC:

  • Major versions (vX.0.0-rc.1 before vX.0.0)
  • Minor versions that touch the ZTP-prem trust boundary (Tier B paths or patent-claim surfaces)
  • Minor versions that change a customer-visible default

Optional RC (maintainer discretion):

  • Minor versions adding a new MÓDULO or Test Kind
  • Patches with non-trivial dependency bumps

RC lifecycle:

  rc.1 → community + maintainer testing → fixes → rc.2 → ... → final

RC tags are signed and pushed to GHCR like final releases; they ship the same SBOM + Cosign attestation. The CHANGELOG entry under the final tag aggregates all RC fixes.

What a release ships

Every release tag (final OR RC) attaches:

  1. Source tag in git, signed
  2. Multi-arch container images at ghcr.io/nollagluiz/web-agent-*:vX.Y.Z
  3. Cosign keyless OIDC signature for each image (per ADR 0005)
  4. SBOM (SPDX, generated by Syft) as a release asset
  5. CHANGELOG.md entry under the right heading
  6. docs/RELEASE-NOTES-vX.Y.Z.md for major + significant minor releases (e.g. docs/RELEASE-NOTES-v3.7.0.md)
  7. release-feed entry at the release-feed branch (consumed by the self-upgrade flow per ADR 0013)
  8. Tier-policy receipt for Tier B builds — the SHA-256 of platform/ztp-prem/tier-policy.yaml matches what shipped with the binaries (per the auditor handoff package)

Release-prep checklist

Before tagging:

  • CHANGELOG.md has an entry under the version being cut
  • docs-link-audit.py reports 0 broken links
  • docs-quickstart-refresh.py ran (idempotent — confirms version stamps in quickstart guides are current)
  • All ADRs in Proposed status that should be Accepted for this release have been flipped
  • No ZTP-prem Tier B file landed without a corresponding ADR delta if its semantics changed
  • Patent-claim surfaces still hold (no silent claim regression)
  • Release notes drafted for the final tag (for majors / big minors) or CHANGELOG diff suffices (for patches)
  • Investor Deck "Verifiable today" slide KPIs match the release reality (33 ADRs / patent count / camada count etc.)

Supported release lines

See BACKPORTING_POLICY.md — that's the authoritative table for which vX.Y lines receive ongoing fixes. At any time the project supports:

  • The latest minor of the current major
  • The previous minor of the current major (overlap window)
  • The latest minor of the previous major (security only)

Everything else is end-of-life.

Why this matters

Procurement teams ask, almost universally: "What's your release schedule?" and "How do you handle versioning?" This document is the answer. It's deliberately honest about being signal-driven rather than calendar-driven (because a solo maintainer who promises a calendar will eventually miss it).

For audit / valuation, the existence of a written cadence policy is a maturity signal — even if the cadence itself is informal.

Last verified against shipping code: v3.7.0 (2026-05-12).