release-policy

Release policy and procedure

Documentation home · Builds and images

Versions 3.x.x are rewrite pre-releases; 4.0.0 is the first production milestone under the operator-approved support scope. Tags and production rollout require explicit operator instruction. Publishing an image does not authorize a deployment change.

Changelog before every tag

The changelog is the canonical release history. Before creating any tag, update it with the version, release date, changes, known limitations and actual publication status. Do this before the release commit and before the annotated tag.

Keep changes since the latest release under Unreleased. During release preparation move them into the versioned section. If implementation changes are already committed, create a separate changelog commit and tag that commit. Never tag first and add the changelog afterwards. Never rewrite a published tag to attach newer documentation; make the next appropriate release instead.

Release sequence

  1. Confirm the working tree, branch, user changes and latest remote tags. Use semantic version ordering rather than alphabetical ordering.
  2. Choose the next explicitly authorized version. For this OCI repository tags are plain MAJOR.MINOR.PATCH, with no v prefix. Features normally increment minor; fixes and packaging changes normally increment patch within the authorized major line.
  3. Update the changelog and affected documentation. Keep historical results attached to their actual binaries; do not invent new runtime results.
  4. Commit the release changes, including the changelog, then push the branch. Release notes must describe implemented behavior, limitations and actual CI image/build metadata. Preserve licence and corresponding-source materials.
  5. Create an annotated tag on that committed source, with clear release notes, then push the tag. Do not force-update an existing tag.
  6. The tag pipeline resolves floating inputs, builds all three role images and publishes their manifests. Report that status accurately; a pushed source tag alone does not mean its final image tags are available yet.
  7. Deployment is a separate explicitly authorized GitOps change. Keep all role versions compatible and follow the quiescent upgrade procedure.

Local builds or tests require explicit operator authorization; the operator requested a package-wide Go check for 4.0.1. This does not restore removed tests or establish behavioral coverage. Only the TLSPU build and manifest jobs run; the old ten-REL validator, artifact-image indirection and custom publication/reproducibility machinery have been removed.

Build identity and security

Compiler, dependency, template and base inputs float. Rebuilding an existing source tag can produce different binaries and image identities. Preserve the actual image/build information when reporting a running release, rather than assuming its tag name reproduces an earlier dependency set. Historical hashes are observations, not active dependency pins.

TAK-OS produces unsigned containers; signing is not required. Managers, cluster administrators and privileged node services remain trusted. Do not copy private keys, bearer tokens or full Secrets into a release record.

Runtime changes and retained data

Stop consumers and complete normal unpublish/unstage before replacing mount owners. Preserve original volume, membership, trust and backing identities. Do not lower quorum, bypass old-member fences or remove protection metadata as a recovery technique. Upgrade/downgrade limits are documented in compatibility; replication is not an external backup.