Versions Compared

Old Version 152

changes.mady.by.user Anton Chernov

Saved on

compared with

New Version 153

changes.mady.by.user Anton Chernov

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents
maxLevel5

 

Overview

Responsibilities

Release manager and release co-manager (if manager is not a committer) The release lead 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 
  • triaging issues

...

  • and re-vote if necessary

...

Finalising and posting a release

...

  • marking & publishing the official release
  • updating the MXNet website
  • announcing the release

...

 

Pre-requisites to become a Release Lead: (based on feedback from Apache MXNet Mentors)

  1. You are a current project committer
  2. 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 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, 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 features must be added to the readme/tutorial

Code Block
languagebash
themeMidnight
titleUse this script to get commits since a particular date
#!/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"


Info
titleNote: Blog post

Check if this release has to go out on a blog on

...

Medium

...

(Sukwon) beforehand. If so, keep time to work on the blog post as this may take a while longer. This blog post needs to go through multiple reviews. 

Step 1.2. Inform the Community of timing

...

You can find references of sent emails, for example for the most recent release

...

, in the apache archive (or your inbox

...

) as well:

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 lead 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. The first release candidate should be on a commit which passed builds from at least 3 days before cutting the release candidate. This will make the release lead's job easier. Below is a template for the

...

announcement:


Info
iconfalse
titleCommunity announcement email template


To: dev@mxnet.apache.org
Subject: [Announce] Upcoming Apache MXNet (incubating) $release release

Dear MXNet community,

I will be the release manager for the upcoming $release release. (Optional: $CO-RM will be co-managing the release and providing help from the committers side.)
A release candidate will be cut on $utc_date and voting will commence $utc_date_vote0 - $utc_date_vote1. Release notes have been drafted here [1]. 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-72.

Feel free to add any other comments/suggestions.

Thanks,
$RM

[1] $release-notes-link

Step 1.3. Check licenses

Make sure all files have correct License headers and the top level LICENSE file has been updated.

  • Any new files added in this release must have a valid license header. 
  • Make sure any new submodules or dependencies that have been added in this release have been mentioned in the top level LICENSE file - There is no test to cover this (and is a frequent cause of a -1)
  • Make sure the Apache RAT test is passing (contact mbaijal@ in case of issues). Run manually on the final commit as mentioned below (will be part of a nightly test soon)
    Link - https://github.com/apache/incubator-mxnet/pull/10390this is ensured automatically by the PR validation check)
  • DISCLAIMER is correct, filenames file names include “incubating”

More Details

...

The top level 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.
  • Any new dependency with a non-ASF license must be added to the top level LICENSE file as directed in the links below.
  • All source files have license headers where appropriate.
  • The provenance of all source files is clear (ASF or software grants)
Some More details

...

Refer to the following Links 

 Step Step 1.4. 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.

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.

Check with the website lead and docs lead that all necessary updates have made it into the release branch

  1. Most updates happen post-release.
  2. Broken link updates in tutorials and faqs would be an exception.

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
languagebash
themeMidnight
titleAdding 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.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.

  • 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
  • Docs should also be manually built locally & checked for correctness. TODO: how to retrieve the commit hash.
  • 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)
  • Update NEWS and README. An example can be followed here: https://github.com/apache/incubator-mxnet/pull/6471. Note that this assumes the 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.

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

Step 1.6. 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)

Nightly Tests

Following jobs are run as a part of the nightly tests:

  • NightlyTests
  • NightlyTestsForBinaries
  • These jobs should already contain needed branches if they are cut. If not, check the jobs configuration. These are triggered by DailyTrigger. Either wait until the jobs have been triggered or trigger them manually.
  • Backward Compatibility checker (currently restricted).
  • Some jobs might take up to 4-5 hours, so plan accordingly.
  • In case of a failure of any job, check the console logs, the newly added PRs and try and resolve issues or contact community for a fix (on

...

  • @dev list, for example). 

Jenkins CI Tests

  • Ensure that PR verification is enabled for the target release branch, for example

...

  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/

RAT Check

...

  • make sure the RAT check passes (it's already part of the verification pipeline as a stage, no special actions needed)

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

...

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.9. Create

...

artefacts for the release and push to the dist folder

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

      • Clone the Repo and checkout the release branch 
      • remove R-package until the licensing issue is resolved
      • Remove all the .git files
      • Remove all other files of the form .* (eg .travis, .DS_Store etc)
      • on MacOS use gnu-tar
      • Try to untar it in a different type of machine and try a classic build with `make`. Follow build instructions in the "Build from Source" section http://mxnet.incubator.apache.org/get_started/install.html

...