ORM Branching

Describes the paradigm used for branching within the ORM project

• main is where we do "latest stable" development. Which specific release family this targets is dependent upon the "critical mass" discussion in The Process.

• "Dedicated release branches" (5.6, 6.0, 6.1, 6.2, …​) represent previous, no longer supported releases. Branched for posterity.

• PR branches for new features, improvements, disruptive bugfixes, etc target main

• PR branches for performance improvements, security fixes and bugfixes target the affected minor branches (which could be main for a short period of time)

Process (using 6.3 → 6.4 as an example):

• As mentioned, all new features, improvements, disruptive bugfixes, etc. are developed on topic branches (PR) against main. Based on sprint planning, these will be given a priority and target a particular major/minor release.

• Once we have critical mass for topic branches targeting 6.4:

• main will be branched as 6.3 and a 6.3.x release will be done.

• The finished topic branches will be integrated into main and a 6.4.0 Alpha (or Beta or CR)[1] release will be done.

• A bot will cherry-pick changes made to the latest "dedicated release branch" (here, 6.3) and create a PR against main (on the assumption that these changes might be needed there as well). TBD if we want to auto-apply these PRs on successful build.

• PRs against older "dedicated release branches", will first be rebased to the latest stable branch and applied. We’ll decide between 6.3 and main based mostly on ; if 6.3, the bot will pick it up.

[1] Historically I am not a huge fan of a full Alpha/Beta/CR cycle for minor releases, usually just doing CRs. But open to convincing otherwise.