...
1. Preparing the Release Candidate:
Step 1.1. Prepare Release Notes
...
Draft release notes which should include the list of new features and bug fixes, along with limitations, known issues, credits, etc. Seek help from committers on @dev to achieve good coverage of all important fixes/API changes in the release.
- All problems/fixes in release notes MUST have the PR link and a possible workaround if any
- new New features must be added to the readme/tutorial.
Code Block | ||||
---|---|---|---|---|
| ||||
#!/bin/bash # to get a list of commits since <date> git log --pretty=format:"%h - %cn, %cd : %s" --no-merges --since="2017-09-01" > commits.txt # To get a list of committers since <date> git shortlog -sne --since="10 Aug 2017" |
...
- 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 More recent example - https://github.com/apache/incubator-mxnet/pull/8567
make sure no broken/non-existing links are added to the master branch.Update NEWS and README. An example can be followed here: https://github.com/apache/incubator-mxnet/pull/6471 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
Code Block language bash title Adding Keys # checkout the
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
...
- 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. Docs should also be manually built locally & checked for correctness. TODO: how to retrieve the commit hash.Manual Docs Build -
- The build_all_versions.sh must also be updated with the correct tag This script must be
3. 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)
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 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 -
- The build_all_versions.sh must also be updated with the correct tag
- This script must be built locally to test docs (confirmprocedure with Santhosh, Yao) and automate after 0.12.0
.
...
- .
...
Step 1.5. Tag release candidate (To be done by a committer)
...