Branching strategy or release process for cmake releases

Hi all,

This is just for my educational purpose. I am trying to learn how cmake community manages so many releases in a clean way. Would like to understand the release process or branching strategy being used in cmake development, if possible.

Thanks
Phani

The official repository publishes 2 integration branches: master and release. New development is merged to master. The current release version (either while preparing release candidates or while maintaining it as a stable release) is published in the release branch. The release branch is always kept merged into master too, but the merge commit messages refer to the branch with its corresponding release number, e.g. Merge branch 'release-3.29'. Anyone can recover older release branches by looking for merge commits with such messages in git log --first-parent master and then taking their second parent. Locally the maintainer keeps separate numbered release-X.Y branches for the occasional backport to older release series.

When a change/fix needs to be backported to the release branch, we use a merge request with a source branch that’s based on the upstream release branch, but that targets master for merging. We use a bot to do merges that knows how to merge to both release and master, and also merge the updated release itself into master to maintain that invariant.

3 Likes

Thanks for your reply :slight_smile: