Skip to content

Release Process

Document ID: IMPL-004
File Path: docs/19-implementation-guide/release-process.md
Version: 1.0.0
Status: Draft
Owner: Engineering Team
Last Updated: 2026-06-27


This document defines how the Wovyr AI Platform is versioned and released — from a merged change to signed, deployable artifacts.


  • The platform follows semantic versioning (MAJOR.MINOR.PATCH).
  • Public contracts have explicit compatibility rules: API, Workflow DSL, Plugin API.
  • Releases align to the roadmap milestones.

main (always releasable)
├─ feature branches → PR → merge to main
└─ release/x.y → stabilization for a minor release

main stays green and releasable; release branches stabilize a version.


1. Cut release/x.y from main
2. Update CHANGELOG + version numbers
3. CI: build → test → package images + SDK
4. Sign artifacts (images, CLI, SDK) + generate provenance/SBOM
5. Publish to registries
6. Tag the release; publish release notes
7. Deploy via Helm/Terraform (staged: canary → full)

Artifact signing mirrors plugin signing (build system).


A release must pass:

  • Unit + integration + contract tests (testing).
  • Performance regression check vs. baseline (performance).
  • Security scans + review for sensitive changes (security testing).

  • Staged rollout (canary → progressive) via Helm with health-gated steps.
  • DB migrations run as pre-deploy jobs; forward-compatible.
  • helm rollback reverts to a prior release if SLOs/alerts regress (alerting).

  • Conventional commits feed an automated CHANGELOG.
  • Release notes call out features, fixes, deprecations, and migration steps.
  • Deprecations announce a window before removal (compatibility commitments).

Critical fixes branch from the affected release tag, follow the same gates (expedited), and are signed/published like any release; revocation is available for compromised artifacts (distribution).



VersionDateDescription
1.0.02026-06-27Initial Release Process