Process/Using Stabilizing Branch
Towards the end of the release cycle bug fixes for the upcoming release must be committed in the stabilizing branch.
- Commit and push bug fixes to the
blender-v2.8X-releasestabilizing branch. This goes for Blender, add-ons and tests.
- Merge the stabilizing branch into
master, where the following release is being developed.
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
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
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.
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.