Skip to content

Branching and Versioning

James Maes edited this page Sep 24, 2026 · 8 revisions

Branching and versioning

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

Normal development uses feature branches and pull requests to develop. The current 4.0 stabilization branch is release/4.0.x. Protected branches require their configured CI and reviews; follow the actual repository rules instead of direct pushes to a protected target.

Ref or version Meaning
feature/* Bounded work under review
develop / -SNAPSHOT Ongoing development; mutable dependency versions
release/4.0.x / 4.0.0-RC.n 4.0 candidate stabilization and acceptance
main with final vX.Y.Z tag Reviewed final release source; publication must still be verified
hotfix/* A scoped correction following the selected repository's workflow

Core artifact group is com.kingsrook.qqq; the BOM artifact is qqq-bom-pom. The QBit parent intentionally uses com.kingsrook:qbit-build-parent, so a different group is not automatically a defect. Repositories and components have independent versions: dashboard uses 0.41.0, and parent 2.0.0 imports final core 4.0.0.

The pinned orb and .circleci/config.yml determine version calculation and publishing triggers. Inspect current remote versions before selecting a new immutable RC or final version. Do not assume every push publishes successfully or that a merge creates a final release automatically.

For a release, complete candidate acceptance and publication, merge fixes back into ongoing development through reviewed PRs, and coordinate cleanup with maintainers. Preserve existing release refs while they are needed for the active train. Follow Semantic Versioning Policy for compatibility and Changelog and Tagging for provenance.

Clone this wiki locally