Page History

...

Step 1.3. Make code changes with necessary version updates

At least 3 days prior to cutting the first release candidate, bump up the version number and address other changes that the release depends on.

1. 1. Bump up the version number. An example can be followed here: https://github.com/apache/incubator-mxnet/pull/6462, update https://github.com/apache/incubator-mxnet/blob/master/setup-utils/install-mxnet-osx-python.sh#L36
      More recent example - https://github.com/apache/incubator-mxnet/pull/8567
      make sure no broken/non-existing links are added to the master branch.

   2. Create a RSA GPG key of length 4096, upload it to the public server, and add it to the KEYS file (do this process once for each release lead): https://github.com/apache/incubator-mxnet/blob/master/KEYS & https://dist.apache.org/repos/dist/dev/incubator/mxnet/KEYS See more detailed instructions on creating the key here: https://www.apache.org/dev/openpgp.html#generate-key. Instructions for updating the KEYS file can be found here: https://github.com/apache/incubator-mxnet/blob/master/KEYS#L9-L13. Note that you must use apache email instead of personal email for the key. 
      

      Code Block
      language bash title Adding Keys
      # checkout the apache mxnet repo svn co https://dist.apache.org/repos/dist/dev/incubator/mxnet apache-mxnet cd apache-mxnet # update the KEYS file ... # commit the update svn commit -m “update keys file for xxx ” --username your_username --password your_passwd

Step 1.4. Cut the Release Branch

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

, nightly tests.

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

...

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

...

1. 1. Update NEWS and README. An example can be followed here: https://github.com/apache/incubator-mxnet/pull/6471. Note that this assumes the existance 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.

   2. 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 with Santhosh, Yao) and automate after 0.12.0.
            
            

Step 1.5

...

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 with Santhosh, Yao) and automate after 0.12.0.

...

Testing the Release Branch

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

1. Nightly Tests - (Currently not public, coming soon!)
   There are currently 9 different jobs that are run as a part of the nightly tests. these must pass as follows - 
   1. Go to the nightly job here - http://jenkins-master-elb-1979848568.us-east-1.elb.amazonaws.com/view/NightlyTest_Release/
   2. For each of the jobs, click on configure and change the branch that it runs on from the previous release to the name of the current release branch. 
   3. Once each job is updated, click on the 'Release_Run-All-Nightly' and click on build now. 
   4. This job might take upto 4-5 hours to build so plan in advance 
   5. After success, click on each job to make sure it ran on the correct commit #. 
   6. In case of a failure of any job, check the console logs, the newly added PRs and try and resolve issues or contact the relevant person for a fix. 
2. Jenkins CI Tests
   1. The release branch must pass the tests on the CI for example, here - http://jenkins.mxnet-ci.amazon-ml.com/job/incubator-mxnet/job/v1.1.0/

Step 1.6. Tag release candidate (To be done by a committer)

1. 1. Go to the GitHub repo’s “releases” tab
   2. Click “Draft a new release”

1. 1. • • Provide the release tag in the form of “1.0.0.rc0” where 0 means it’s the first release candidate
        • Select the commit by clicking Target: branch > Recent commits > $commit_hash 
        • Copy and paste NEWS.md change into the description box from here
        • Select “This is a pre-release"

Step 1.

...

7. This step has not been done in the past 

Tag all the dependent submodules for every MXNet release. If a code-change (e.g. bug-fix) is required to a dependent sub-module then we take a branch from the tag and apply the code-change only to the branch for the sub-module so that the change is minimal. This should allow the MXNet release process to have better convergence towards a stable release.

Step 1.

...

8. Create artifacts for the release and push to the dist folder

a) The src tar - apache-mxnet-src-#.#.#.rc0-incubating.tar.gx:

...