Page History

...

Step 1.5. Cut the Release Branch

Note: From version 1.3 all branches are created with a name v1.3.x to make patch releases easier. For patch releases cutting a new branch is not necessary. Fixes for patch releases should be merged to v#.#.x branch and latest commit should be tagged with an exact version number, ie v1.3.1.

1. 1. The release candidate should contain all planned features, bug fixes, and code changes above. The release candidate commit should have passed the merge build, pip builds

   2. Docs should also be manually built locally & checked for correctness. TODO: how to retrieve the commit hash.

   3. Checkout the commit into a new branch "v#.#.#x" and push it (It might be a good idea to do this in advance and freeze the branch)

   4. Update NEWS and README. An example can be followed here: https://github.com/apache/incubator-mxnet/pull/6471. Note that this assumes the existance existence of the tag of next release, which is not created yet. Therefore, the update only happens on the release branch (not the master branch) so broken links are not visible to users.

   5. Manual Docs Build - 

1. 1. 1. 1. The build_all_versions.sh must also be updated with the correct tag
         2. This script must be built locally to test docs (confirmprocedure confirm procedure with Santhosh, Yao) and automate after 0.12.0.
            
            

...

Once all the PRs have been merged the final commit hash on the release branch must be tested. (You should begin testing as soon as the release branch is created, but make sure it is run atleast once on the final commit)

...