Skip to content

Latest commit

 

History

History
25 lines (18 loc) · 1.76 KB

branching.adoc

File metadata and controls

25 lines (18 loc) · 1.76 KB

ORM Branching

Describes the paradigm used for branching within the ORM project

The Branches

  • 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)

The Process

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.