Skip to content

branching.adoc

Latest commit

 

History

History
36 lines (26 loc) · 2.33 KB

branching.adoc

File metadata and controls

36 lines (26 loc) · 2.33 KB
Raw

Hibernate NoSQL Branching

Describes the paradigm used for branching within the Hibernate NoSQL 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.

CI related branch fixups

The GHA (GitHub Action) workflow, that is checked into the repository at .github/workflows/ci.yml, refers to the branch name it applies to, which is typically main. When branching off for a new major/minor release, the reference to the branch name needs to be updated, in order for workflows to run again on pull requests against that branch.

At the very top of the file in the section on > push > branches and on > pull_request > branches, replace the main branch name with the correct branch name.