Overview
The release manager role in Apache MXNet means you are responsible for a few different things:
- Preparing for release candidates:
- informing the community of timing
- prepare release notes (bug fixes, features added)
- making code changes with necessary version updates
- cutting a release candidate
- Running the voting process for a release:
- calling votes and triaging issues, revote if necessary
- Finalizing and posting a release:
- marking & publishing the official release
- updating the MXNet website
- announcing the release
Pre-requisites:
- You are a current project committer
- You’ve gained access to configure build jobs at builds.apache.org as a part of the jobsadmin group (ask a PMC mentor to add you)
1. Preparing for release candidates:
1. prepare release notes (bug fixes, features added)
Draft release notes which should include the list of new features and bug fixes, along with limitations, known issues, credits, etc.
2. informing the community of timing
After every release, the community should decide on a list of features to deliver for the following release. When the clear target date for a release has been estimated, the release manager should inform the community of the release schedule. All features which the community wishes to include in the release should be merged and tested successfully before the date of the first release candidate. Below is a template for the information:
To: dev@mxnet.apache.org
Subject: Release plan - MXNET 0.11
We are starting the process to prepare for MXNET $release release. We have drafted release notes ($link) to cover the tasks under this release.
A release candidate will be cut on $utc_date and voting will commence $utc_date_vote0 - $utc_date_vote1. If you have any additional features in progress and would like to include it in this release, please assure they have been merged by $utc_date-24 comment so we may update the release notes.
Feel free to add any other comments/suggestions.
Thanks,
$RM
3. making code changes with necessary version updates
- Bump up the version number. An example can be followed here: https://github.com/apache/incubator-mxnet/pull/6462
- 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 manager): https://github.com/apache/incubator-mxnet/blob/master/KEYS See more detailed instructions on creating the key here: https://www.apache.org/dev/openpgp.html#generate-key
4. cutting a release candidate
- 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.
- Tag release candidate and export source package
- Go to the GitHub repo’s “releases” tab
- Click “Draft a new release”
- Provide the release tag in the form of “v#.#.#.rc0” where 0 means it’s the first release candidate
- Select the commit by clicking Target: master > Recent commits > $commit_hash
- Copy and paste NEWS change into the description box
- Select “This is a pre-release"
- Source packages will be created. Download the .tar.gz to name it "apache-mxnet-src-#.#.#.rc0-incubating.tar.gz"
- Create remaing artifacts for the release and push to the dist folder
- apache-mxnet-src-#.#.#.rc0-incubating.tar.gz.asc: Create OpenGPG compatible ASCII armored detached signature http://www.apache.org/dev/release-signing.html#openpgp-ascii-detach-sig
- apache-mxnet-src-#.#.#.rc0-incubating.tar.gz.md5: Create MD5 checksum http://www.apache.org/dev/release-signing.html#md5
- apache-mxnet-src-#.#.#.rc0-incubating.tar.gz.sha512: Create SHA checksum http://www.apache.org/dev/release-signing.html#sha-checksum
- KEYS: Add your public signing key to the dist folder
- #.#.#-incubating.RC0 folder: Create a folder for this RC in the dist folder
# Checkout the Apache directory in Apache distribution SVN "dev" repo
$ svn co https://dist.apache.org/repos/dist/dev/incubator/mxnet
# Make directory for this RC in the above directory
mkdir #.#.#.rc0
# Move artifacts into this folder
TODO
$ svn add mxnet-#.#.#.rc0
$ svn commit -m "Add mxnet-#.#.#.rc0" --username "lxn2"
# Move the sub-directory in "dev" to the
# corresponding directory in "release"
$ export SVN_EDITOR=vim
$ svn mv https://dist.apache.org/repos/dist/dev/incubator/mxnet/mxnet-#.#.#.rc0 http://www.apache.org/dist/incubator/mxnet/mxnet-#.#.#.rc0
Verify that the resources are present in http://www.apache.org/dist/incubator/mxnet. It may take a while for them to be visible. This will be mirrored throughout the Apache network. There are a few remaining steps.
3. Validate release package
As per the Apache documentation, verify that the release candidate artifacts satisfy the following:
- PGP signatures and SHA256/MD5 checksum verification
Example (performed on a Macbook Pro: brew install gpg2 coreutils):
$ brew install gpg2 coreutils
$ gpg2 --import ../KEYS
$ gpg2 --verify apache-mxnet-src-#.#.#.rc0-incubating.tar.gz.asc
$ gsha256sum --check apache-mxnet-src-#.#.#.rc0-incubating.tar.gz.sha256
$ gmd5sum --check apache-mxnet-src-#.#.#.rc0-incubating.tar.gz.md5
- Build is successful
- DISCLAIMER is correct, filenames include “incubating”
- LICENSE and NOTICE files are correct and dependency licenses are acceptable
- LICENSE and NOTICE files at the root of the artifact directory must only reflect the contents of the artifact in which they are contained.
- See:
- LICENSE file requirements
- LICENSE requirements for distribution artifacts with multiple licenses
- NOTICE file requirements (Check Copyright year) - see also https://www.apache.org/legal/src-headers.html
- Apache Legal
- Acceptable and Unacceptable Dependency Licenses
- All source files have license headers where appropriate, RAT checks pass - TODO - add instructions - see https://creadur.apache.org/rat/
- The provenance of all source files is clear (ASF or software grants)
2. Running the voting process for a release:
1. calling votes and triaging issues, revote if necessary
The full voting process is two phases: 3 days on dev@mxnet.apache.org, 3 days on http://general@incubator.apache.org.
For the dev@ vote, there must be at least 3 +1 votes and more +1 votes than -1 votes. Once that quorum has been reached, the vote then moves onto the general@ vote, where anyone can contribute a vote, but only MXNet PMC votes are binding. To pass, there must be 3 +1 PMC votes and more +1 votes than -1 votes. Send out a notice to vote. Email template:
To: dev@mxnet.apache.org
Subject: [VOTE] Release MXNet version 0.11.0
This is the vote to release Apache MXNet (incubating) version 0.11.0. Voting will start now and close $utc_now+72.
Link to release notes: <Link>
Link to release candidate 0.11.0.rc0: <Link>
Link to pip build: <Link>
Please test and vote accordingly:
+1 = approve
+0 = no opinion
-1 = disapprove (provide reason)
Once each vote is complete, send out a results email:
To: dev@mxnet.apache.org
Subject: [RESULTS] [VOTE] Release MXNet version 0.11.0
This vote passes with 7 +1 votes (3 bindings) and no 0 or -1 votes.
+1 votes
PMC Members:
* $Name
* $Name
* $Name
Committers:
* $Name
* $Name
Community:
* $Name
* $Name
0 votes
* No votes
-1 votes
* No votes
Vote thread:
https://lists.apache.org/list.html?commits@mxnet.apache.org/
I'll continue with the release process and the release announcement will follow in the next few days.
$RM
Should any vote fail to reach quorum, the release manager should triage the issues, create GitHub issues, and move to fix the issues. Once fixed, mark the issues as FIXED in the new README, release notes, and description when drafting a new release for a second release candidate. Repeat until the vote passes.
3. Finalizing and posting a release:
1. marking & publishing the official release
Once the release candidate passes the vote, we draft the official release on GitHub and rename the release candidate as the official release.
Draft official release on GitHub:
- Go to the GitHub repo’s “releases” tab
- Click “Draft a new release”
- Provide the release tag in the form of “v#.#.#”
- Select the commit by clicking Target: master > the passing release candidate tag
- Copy and paste NEWS change into the description box
Download the nightly pip build, rename, and publish:
- TODO
Rename and publish the source package:
- TODO
Build, test, and publish the Docker images:
- TODO
- test multinode and multi gpu (kvstore=1)
2. updating the MXNet website
Now that a new version has been drafted on GitHub with source and pip packages published, we need to update the MXNet website. Go to builds.apache.org and find job “incubator-mxnet-build-site”. Click “Build with Parameters”, select the release tag, and build. The docs will be published to incubator.mxnet.apache.org.
Manually update the website’s download links:
- TODO: link to Apache mirror source, pgp, sha, md5
3. announcing the release
Once everything is working (website docs, website changes, 24 hours after upload) create an announcement on the website and then send an e-mail to the mailing list. http://www.apache.org/legal/release-policy.html#release-announcements
Send an email to announce@apache.org, general@incubator.apache.org, and dev@mxnet.incubator.apache.org with the subject: [ANNOUNCE] Apache MXNet <release number> Release and a body along the lines of:
Apache MXNet (incubating) Project Team is proud to announce Apache *Download Link*: <Link>
Apache MXNet (incubating) is an effort undergoing incubation at The
|
Enjoy an adult beverage (or bubble tea) of your choice, and congratulations on making a MXNet release.
****************************************************
Notes for reference:
*NOTES FROM DOCS FOR REFERENCE:* http://incubator.apache.org/guides/releasemanagement.html - 3 +1 votes from IPMC members (these are the votes that count but we should open up to the whole podling community) - For podlings, 2 additional constraints: - Release artifacts must include “incubating” in final file name (ex: apache-mxnet-src-0.10.1-incubating.tar.gz) - Release artifacts must include disclaimer in the release artifacts - The Incubator PMC expects the source releases to be staged on https://dist.apache.org/repos/dist/dev/incubator/podlingName so that they can easily be moved to the release location via svn mv ( http://www.apache.org/dist/incubator/) - After graduating, RC’s go into https://dist.apache.org/repos/dist/dev/ and official releases go into https://dist.apache.org/repos/dist/release/ http://incubator.apache.org/guides/branding.html#disclaimers - Apache Press Team [http://www.apache.org/press/index.html#whoweare] must review and coordinate releases for branding - On website and in release DISCLAIMER file: - Apache Podling-Name is an effort undergoing incubation at The Apache Software Foundation (ASF), sponsored by the name of Apache TLP sponsor. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF. - Website should include Apache Incubator logo: http://incubator.apache.org/guides/press-kit.html - Release should include: - DISCLAIMER - LICENSE - NOTICE - attribution notices http://www.apache.org/legal/release-policy.html - A release must contain source package which is cryptographically signed by Release Manager with detached signature. It must be tested prior to voting for release. - Release must only contain appropriately licensed code - Please ensure you wait >=24 hours after uploading a release before making announcements so mirrors catch up - Releases of more than 1GB of artifacts require a heads-up to Infrastructure in advance. - Which directory for what build? http://www.apache.org/legal/release-policy.html#build-directories http://www.apache.org/dev/release-distribution.html - Artifacts MUST be accompanied by: - apache-mxnet-src-0.10.1-incubating.asc - contains OpenPGP compatible ASCII armored detached signature - apache-mxnet-src-0.10.1-incubating.md5 - MD5 checksum - apache-mxnet-src-0.10.1-incubating.sha - SHA checksum (SHOULD) - Publish KEYS file in distribution directory root - Signing keys MUST be published in KEYS file, SHOULD be available in global public keyserver http://www.apache.org/dev/release-signing#keyserver, SHOULD be linked into web of trust - Keys MUST be RSA & 4096 bits http://www.apache.org/dev/release-publishing.html - Apache RAT can assist in checking license compliance http://creadur.apache.org/rat/ - Eventually we should set up a build system to sign our releases with cryptographic signatures. For now we’ll do it manually. http://www.apache.org/dev/release-signing.html - Create a signature and sign releases as mentioned above