THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
- Most updates happen post-release.
- Broken link updates in tutorials and faqs would be an exception.
Step 1.5. Add RSA GPG key of release manager/co-manager to repository
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 | ||||||
|---|---|---|---|---|---|---|
| ||||||
# 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.
...
6. 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.
...
- The build_all_versions.sh must also be updated with the correct tag
- This script must be built locally to test docs (confirm procedure with Santhosh, Yao) and automate after 0.12.0.
Step 1.
...
7. Test the release branch
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)
...
- make sure the RAT check passes (it's already part of the verification pipeline as a stage, no special actions needed)
Step 1.
...
8.
...
Tag release candidate (To be done by a committer)
- Go to the GitHub repositories “releases” tab
- Click “Draft a new release”
- 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.
...
9.
...
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.
...
10. Create artefacts for the release and push to the dist folder
The src tar - apache-mxnet-src-#.#.#.rc0-incubating.tar.gz:
...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
# Checkout the Apache directory in Apache distribution SVN "dev" repo $ svn co https://dist.apache.org/repos/dist/dev/incubator/mxnet # select p # Make directory for this RC in the above directory $ cd mxnet $ mkdir #.#.#.rc0 # Move artifacts into this folder $ cp ../apache-mxnet-src-#.#.#.rc0-incubating.tar.gz* #.#.#.rc0 $ svn add #.#.#.rc0 $ svn commit -m "Add mxnet-#.#.#.rc0" --username "lxn2" |
Step 1.
...
11. Validate release package (Committer or Contributor)
As per the Apache documentation, verify that the release candidate artifacts satisfy the following:
...
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
gpg --verify ./apache-mxnet-src-0.11.0.rc3-incubating.tar.gz.asc gsha512sum --check ./apache-mxnet-src-0.11.0.rc1-incubating.tar.gz.sha512 |
Step 1.
...
12. Test the final release package (Committer or Contributor)
- Download the package that was just uploaded to svn as above.
Test that a build is successful - spinning up a deep learning Ubuntu AMI will give you an environment with all dependencies to build. For example:
...
If possible, run a simple (MNIST) test to verify the src.
Step 1.
...
13. Upload the release artifacts to Github release tag
- Edit the release tag from Step 1.7, and upload the release artifacts from Step 1.9 (which were verified in 1.10-1.11).
- After creating RC, give 2 days to build scala/ R packages if needed before starting vote on dev@.
Step 1.
...
14. Language bindings
Follow the guides for the corresponding language bindings.
...