I am experimenting with a trunk-based development workflow with my team, where we prepare releases by cherry-picking commits from a trunk branch. The workflow for developers is essentially:
- Create a feature branch (for new features / bug-fixes / etc)
- Pull request once work is complete and ready for review
- After review and approval, squash and merge into trunk branch
- Repeat
My question is: How do we correctly create a release branch with this workflow?
From the previous release branch?
From a specific commit?
From nothing (orphan branch)?
Thoughts
Throughout development we cherry-pick commits into a release branch (for QA, demo use, customer feedback, etc). This process is working well because it minimizes the burden on the development team, and we know exactly what features make it into a release. It has improved our pipeline, because the team has no need to engage in development freezes and/or be concerned with merging into the correct (release/hotfix) branch.
A potential downside is release branches that are divergent from the trunk, but that has not been a concern for us so far. In principle, every commit that ever makes it into trunk makes it into a release branch, current or future.
So far we've been making due by choosing a commit in trunk that contains no commits meant for the next release, and usually none or few commits for the current release, then we cherry-pick everything relevant into the release branch. That seems clumsy and I have concerns.
Does it make sense to create a release branch from the previous release branch, and then cherry-pick from trunk at that point? I don't see a downside considering the branch is already divergent. We never intend on deleting the release branches, because they are effectively our tagged releases. It's logical in the sense that each release is based on the previous release, but we're not confident we're not creating future problems.