Skip to main content

Create Feature Branch for Approval

In the subsequent process we will distinguish a major release approval like CMCC v12.2506.0.0 and a minor release approval like CMCC v12.2406.1.0.

INFO: Merge Commit Representing GitHub Pull Request Base

The merge commit used in the graphs is just to represent a base to compare the changes with. This is suitable for reviewers, so that they get an overview of the applied changes. Only PRs with base main will later be merged.

It uses the reverse commit type (shown as X) to signal, that it has not been merged yet.

For each new approval of a CMCC version, we need to apply updates to the GCC repository (new API, new or updated dependencies and alike).

When starting the approval process, a new branch needs to be created from either the main branch (for major versions) or from the related maintenance branch (for minor versions).

git switch --create --track "maintenance/2506.x" "origin/main"
git push --set-upstream origin "maintenance/2506.x"
git switch --create --track "approval/2506.x" "origin/main"

For a fresh approval of a major release, we create a new maintenance branch from main and an approval branch from main as well. For a minor release, we just create an approval branch from the related maintenance branch. This way, the subsequent steps for a major and minor release are almost identical.

INFO: Protected Branches

The branch main as well as all branches matching pattern maintenance/* are protected branches in GitHub. This means that you cannot push directly to these branches, but need to create a pull request for merging your changes. This is a safety mechanism to prevent unintended changes to these branches.