Release Flow

QQQ 4.0 release flow

QQQ 4.0 release. Final 4.0.0 is available. See QQQ 4.0 for release scope and migration guidance.

QRun maintainers own release decisions, validation, and approvals. The 4.0 release requires verified source, successful publication, and first-party application acceptance using QRun's sample and starter. Required validation must be reproducible with QRun-controlled repositories, accounts, and disposable fixtures, without a downstream organization's data or approval. CI automation performs defined jobs; a branch push or a green local build does not itself complete the release.

1. Prepare and review the core, sample, starter, QBit parent, and three templates. Record exact signed source references and required local checks.
2. Complete required CI and code-owner review on the core stabilization PR targeting release/4.0.x.
3. Publish the next unused release candidate through the configured candidate workflow. Verify all 18 core coordinates and their provenance in the public registry.
4. Test the exact published candidate in the QQQ sample and qqq-app-starter, and record QRun's first-party acceptance evidence. Fixes require a new immutable candidate and renewed acceptance.
5. Complete final release review, merge through the protected workflow, and trigger the configured final tag publication. Verify final 4.0.0 artifacts before advertising general availability.
6. Publish com.kingsrook:qbit-build-parent:2.0.0 only after its imported final core BOM is available. Complete starter/template publication and QRun-owned integration checks in dependency order.
7. Update documentation and marketing availability only after verifying what is actually public. Record tags, source commits, registry checks, and deployment evidence.

The release uses Material Dashboard 0.41.0. Production business qBits, frontend replacement, and AWS SDK migration are separate scopes. Do not overwrite an existing release version or infer an acceptance sign-off from elapsed time.

See QQQ 4.0, CI configuration, and Changelog and Tagging.

For 4.0, the 48 source-coverage groups and separate published-stage train.bom coverage group (#627) are deferred under #534. The ledger reports those gaps; required release tests, BOM/artifact/signature verification and clean-cache public-artifact acceptance still apply.