Process/Using Stabilizing Branch

Stabilizing Branch

Overview

Towards the end of the release cycle bug fixes for the upcoming release must be committed in the stabilizing branch.

In short:

  • Commit and push bug fixes to the blender-v2.8X-release stabilizing branch. This goes for Blender, add-ons and tests.
  • Merge the stabilizing branch into master, where the following release is being developed.

Details

Below the blender-v2.81-release branch is used as an example.

Commit to the Stabilizing Branch

Ensure you are on the correct stabilizing branch, and update to the latest changes.

git checkout blender-v2.81-release
make update

make update will set all submodules and tests to their corresponding stabilizing branches. If you have local changes to Blender or submodules, it will skip updating those repositories. You'll need to commit (or remove) the local changes first.

Once you have your local blender-v2.81-release up-to-date you can make your fix with the care you would do in normal master development.

Once done, necessary commits to fix have been made, and you’ve checked everything is fine, you can push your changes. As a reminder: always commit _only_ that what _you_ have actually changed. If you see unrelated changes, just don’t stage nor commit.

Now, there is a second step you need to do...

Merge to Master

Once you’ve successfully pushed your changes to blender-v2.81-release it is time to also merge that change to master.

git checkout master
make update

You should have latest master now. You’re ready to merge:

git merge blender-v2.81-release

Pay attention to the output. Resolve conflicts if necessary. As always double-check your changes before pushing. If everything looks fine go ahead and push.

Submodules

If you need to make fixes in a submodule, then do similar steps as above and handle pushes and merges with similar care. The only difference is that make update is not needed.