Multi Repo Workflow

Coordinating the 4.0 release train

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

The first train includes qqq and its sample, qbit-bom, qqq-app-starter, and the application, data, and extension QBit templates. Marketing, hosted documentation, and this wiki are reviewed alongside them. Production business qBits and frontend replacement have separate scopes.

Track exact dependencies

For each repository, record the source branch and commit, required upstream version, relevant checks, and publication route. Link dependent issues and PRs. An installed local artifact can prove integration but does not prove public registry availability.

Core candidate publication and QRun's exact-candidate acceptance in the QQQ sample and qqq-app-starter come first. Final com.kingsrook.qqq:qqq-bom-pom:4.0.0 must be public before the parent com.kingsrook:qbit-build-parent:2.0.0 can be published. Starter and templates must resolve their selected dependencies and pass their own checks using QRun-owned test hosts. Production QBit versions remain the consuming application's explicit choice.

Frontend versions do not automatically match core versions: this train retains Material Dashboard 0.41.0. A new qBit is not automatically registered or certified merely by using the build parent. Verify its metadata producer and host integration.

Keep publication claims aligned across READMEs, source docs, hosted docs, wiki, and marketing. Record the final source refs, CI results, artifacts, and first-party application/integration and deployment evidence. Release Flow defines the acceptance gate; Compatibility Matrix states the train boundary.