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-v3.XX-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-v3.4-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.

`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-v3.4-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
As soon as you’ve successfully pushed your changes to `blender-v3.4-release` it is time to also merge that change to `master`.

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

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.

Subversion
The libraries in the Tools/Subversion repository also gets a tag for the release. Note that any library changes made in bcon 3-5 should be committed to that tag as well (as there is no difference in Subversion between tags and branches).

Merging Tests and Libraries
Most of the time tests and libraries are unchanged, but changes in them need to be merged from the release branch. The steps for this are:


 * When working on the git release branch, ensure you have run `make update` so the svn branches match the git branch.
 * Commit test or library changes to the subversion release branch that has been checked out.
 * For merging, check out the master git branch and again ensure you have run `make update` so that the trunk svn branch is checked out.
 * Subversion merging is then done as follows.