Overview
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 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 to become a Release Lead: (based on feedback from Apache MXNet Mentors)
- 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 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
#!/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"
Step 1.2. Inform the Community of timing
Recommendation: While we have added email content in this wiki, it would be best to refer to emails that were sent for the most recent release. You can find them in the apache archive (or your inbox!):
- https://mail-archives.apache.org/mod_mbox/incubator-general/201708.mbox/browser
- https://lists.apache.org/list.html?dev@mxnet.apache.org
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 information:
To: dev@mxnet.apache.org
Subject: Release plan - MXNET 0.11
I am starting the process to prepare for MXNET $release release. I 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-72 comment so I may update the release notes.
Feel free to add any other comments/suggestions.
Thanks,
$RM
Step 1.3. 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/10390 - DISCLAIMER is correct, filenames 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
- MXNet Source Licenses
- 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
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
- Most updates happen post-release.
- 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.
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
- 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
Step 1.5. Cut the Release Branch
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#.#.#" 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 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.
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.6 Test 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)
- 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 -- Go to the nightly job here - http://jenkins-master-elb-1979848568.us-east-1.elb.amazonaws.com/view/NightlyTest_Release/
- 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.
- Once each job is updated, click on the 'Release_Run-All-Nightly' and click on build now.
- This job might take upto 4-5 hours to build so plan in advance
- After success, click on each job to make sure it ran on the correct commit #.
- 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.
- Jenkins CI Tests
- 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, for now run it manually as indicated here - https://github.com/apache/incubator-mxnet/pull/10390
Step 1.7. Tag release candidate (To be done by a committer)
- Go to the GitHub repo’s “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.8. This step has not been done in the past ![(question)](/confluence/s/34gb19/8804/10mvnxf/_/images/icons/emoticons/help_16.svg)
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 artifacts for the release and push to the dist folder
a) The src tar - apache-mxnet-src-#.#.#.rc0-incubating.tar.gx:
- 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
git clone git@github.com:apache/incubator-mxnet.git --recursive apache-mxnet-src-0.12.0.rc0-incubating git checkout v0.12.0 git submodule update --init --recursive git checkout 0.12.0.rc0 rm -rf R-package/* rm -rf R-package rm -rf .DS_Store rm -rf CODEOWNERS rm -rf .git* brew install gnu-tar gtar -czvf apache-mxnet-src-0.11.0.rc3-incubating.tar.gz apache-mxnet-src-0.12.0.rc0-incubating
b) apache-mxnet-src-#.#.#.rc0-incubating.tar.gz.asc:
details here: http://www.apache.org/dev/release-signing.html#openpgp-ascii-detach-sig
c) Create MD5 checksum : apache-mxnet-src-#.#.#.rc0-incubating.tar.gz.md5
d) Create SHA checksum: apache-mxnet-src-#.#.#.rc0-incubating.tar.gz.sha512
gpg --armor --output apache-mxnet-src-0.11.0-incubating.tar.gz.asc --detach-sig apache-mxnet-src-0.11.0-incubating.tar.gz md5 apache-mxnet-src-0.11.0-incubating.tar.gz > apache-mxnet-src-0.11.0-incubating.tar.gz.md5 shasum -a 512 apache-mxnet-src-0.11.0-incubating.tar.gz > apache-mxnet-src-0.11.0-incubating.tar.gz.sha512
e) Create a folder for this RC in the dist folder: 0.12.0-incubating.RC0 folder
# 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.10. Validate release package (Committer or Contributor)
As per the Apache documentation, verify that the release candidate artifacts satisfy the following:
- PGP signatures and SHA256/MD5 checksum verification -
svn co https://dist.apache.org/repos/dist/dev/incubator/mxnet && cd mxnet/#.#.#.rc0 brew install gpg coreutils gpg --import ../KEYS
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 gmd5sum --check ./apache-mxnet-src-0.11.0.rc3-incubating.tar.gz.md5
Step 1.11. 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. A `make -j $(nproc) USE_OPENCV=1 USE_BLAS=openblas USE_CUDA=1 USE_CUDA_PATH=/usr/local/cuda USE_CUDNN=1` should do.
- if Possible, run a simple (mnist) test to verify the src.
Step 1.12. 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).
Step 1.13. Build Scala Packages
Follow the release process to build Scala packages and include the stage repo links in the voting email.
2. Running the voting process for a release:
Step 2.1. Vote on dev@
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: OPENING A VOTE TO DEV@ To: dev@mxnet.apache.org Subject: [VOTE] Release MXNet version 0.11.0.RC# 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 scala packages on the staging repo: <Link>
Please remember to TEST first before voting accordingly: +1 = approve +0 = no opinion -1 = disapprove (provide reason) |
---|
Step 2.2. Send out the Vote Results on dev@
EMAIL TEMPLATE: VOTING RESULTS To: dev@mxnet.apache.org Subject: [RESULTS] [VOTE] Release MXNet version 0.11.0.RC# 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. |
---|
Step2.3. Triage issues and revote if necessary
Should any vote fail to reach quorum or release lead determines that another RC needs to go out, the release lead should triage the issues, create GitHub issues, and move to fix the issues. Once fixed, make changes to NEWS & README.md in case it specifically lists the old RC# number. Start the process for another release candidate. In the new voting email, detail what has changed since the last release candidate. Repeat until the vote passes.
EMAIL TEMPLATE: CANCEL A VOTE To: dev@mxnet.apache.org Subject: [CANCELLED] [VOTE] Release MXNet version 0.11.0.RC# We are CANCELLING this vote because... We will address this issue and send out RC#+1 for another vote. |
---|
Step 2.4. Start a vote on general@
To get the fingerprint of your keys, run `gpg2 --list-keys --fingerprint`
EMAIL TEMPLATE: OPEN A VOTE TO GENERAL@ This is a call for a releasing Apache MXNet (incubating) #.#.#, release |
---|
3. Finalizing and posting a release:
3.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.
Step 3.1.1: 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 “0.12.0”
- Select the commit by clicking Target: master > the passing release candidate tag
- Copy and paste NEWS change into the description box
Step 3.1.2: Rename and publish the source package:
First upload to dev and then move to releases as follows
#create a directory under releases - https://httpd.apache.org/dev/release.html
This process needs to change -> http://www.apache.org/dev/release-download-pages.html
# Step 1: Download and Untar tar -zxvf apache-mxnet-src-0.11.0.rc3-incubating.tar.gz # Step 2: rename (remove the rc) and tar again mv apache-mxnet-src-0.11.0.rc3-incubating apache-mxnet-src-0.11.0-incubating gtar -czvf apache-mxnet-src-0.11.0-incubating.tar.gz apache-mxnet-src-0.11.0-incubating # Step 3: Resign now # Step 4: First upload here - svn mv https://dist.apache.org/repos/dist/dev/incubator/mxnet/0.11.0/ # Step 5: Move from dev to release svn mv https://dist.apache.org/repos/dist/dev/incubator/mxnet/0.11.0/ https://dist.apache.org/repos/dist/release/incubator/mxnet/ --message "0.11.0 release moving from dev to release repo" # Wait 24hours for the src mirroring. The final download page for the announce email is somewhere here (example 0.11.0) - https://www.apache.org/dyn/closer.cgi/incubator/mxnet/0.11.0-incubating/
Step 3.1.3: Download the nightly pip build, rename, and publish:(by Sheng)
Step 3.1.4: Build, test, and publish the Docker images: (by Meghna)
This was done as follows in 0.11.0. In the future use the automated pipeline -
- Update the tag in the tool.sh file or select the correct tag in the Jenkins Job
- Select the correct Repo name = mxnet
- Trigger the Job with IS_PUBLISH=false
- Login to the slave and test each image for correct version by checking logs and/or Readme.
- Manually upload the 20 images that are built.
- Make sure to update the latest and previous docker images
Step 3.1.5: Verify the resources are uploaded
Check 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.
Step 3.1.6: Test
Test multinode and multi gpu (kvstore=1)
3.2. Update 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.
- Add the new installation version on the install page:
- Set the new version to be default. See this example: docs/_static/js/options.js.
- Add the option and all of the new selector classes. See this example: docs/install/index.md.
- Add news about the new release. See this example: docs/_static/mxnet-theme/index.html.
- Add download links to the install archives. See this example: docs/install/download.md.
- Update the pip package table: http://mxnet.incubator.apache.org/install/ubuntu_setup.html
- Go to http://jenkins.mxnet-ci.amazon-ml.com/and find job “restricted-website-build”. Login if you're not already.
- Click Configure and look for the section with the String Parameters.
- Tags to build
- If this is a minor release, the branch should already be in the first parameter "tags_to_build".
- If this is a major release, you will need to add the branch to the list in the Default Value field. Note these are semicolon separated values.
- Tag list
- If this is a minor release, you will want to bump the version up for the branch you're updating. Example: change 1.2.0 to 1.2.1.
- If this is a major release, you will need to add the new version number to the list. Example: add 1.3.0. Note these are semicolon separated values.
- Click Save.
- Click “Build with Parameters”, verify that the settings you just updated look correct, then click Build.
- The docs will be published to http://mxnet.incubator.apache.org/. There can be a delay due to some edge caching with Apache infra. The restricted-website-build job also runs four times a day.
- Add the new installation version on the install page:
Not Sure Manually update the website’s download links:
- TODO: link to Apache mirror source, pgp, sha, md5
3.3. Update NEWS.md & README.md on the MXNet master branch ( can happen after the announcement).
3.4. Review the announcement email content on private@mxnet.incubator.apache.org before sending the announcement.
3.5. Check if this release has to go out on a blog on blogs.apache.org (Sukwon)
In order to get write access to blogs.apache.org/mxnet, one need to first register on blogs.apache.org and ask Henri (bayard@apache.org) to grant the permission.
3.6. Announce 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:
subject: [ANNOUNCE] Apache MXNet 0.11.0 Release
The Apache MXNet community is happy to announce Apache MXNet version 0.11.0! We hit some major milestones with this release! This is our first official release as an incubating Apache project. The project has now fully migrated its codebase and website to Apache. This release includes code contributions from developers from Apple, Samsung, Microsoft and many other. We have also crossed over 400 contributors on the project so far. The 0.11.0 release features Apple Core ML model converter, Support for Keras v1.2.2.
ADD A DESCRIPTION! - A Flexible and Efficient Library for Deep Learning
A blog that explains an end to end use case of building an ios app using MXNet and Core ML:
The AWS blog that highlights the key features of the release: https://aws.amazon.com/blogs/ai/apple-core-ml-and-keras-support-now-available-for-apache-mxnet/
A full list of the changes in this release can be found in the release notes: https://cwiki.apache.org/confluence/display/MXNET/MXNet+0.11.0+Release+Notes
Link to Download: http://www.apache.org/dist/incubator/mxnet/
To build this project, view this page and select “Build from Source”: http://mxnet.incubator.apache.org/get_started/install.html
The Docker Images can be found here: https://hub.docker.com/u/mxnet/
The Pip package can be found here: https://pypi.python.org/pypi/mxnet
The Release Tag is here: https://github.com/apache/incubator-mxnet/tree/0.11.0
MXNet Resources - Issues: https://github.com/apache/incubator-mxnet/issues - Wiki: https://cwiki.apache.org/confluence/display/MXNET - Mailing list(s): dev@mxnet.incubator.apache.org
For more information on Apache MXNet, please see: https://mxnet.incubator.apache.org/
Thanks! Apache MXNet(incubating) Team _______
DISCLAIMER: Apache MXNet (incubating) is an effort undergoing incubation at The Apache Software Foundation (ASF), sponsored by the name of Apache Incubator PMC. 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.
|
---|
3.7. Bump up the versions on the master
Once the release is complete, make sure that all PRs that were created during the release process only for the release branch (version updates, README NEWS etc) are now merged into the master branch too.
- Merge the PR you created for the release branch into the master
- Add a new PR to update the version to one up/or next release for pip-releases
3.8. Clean up older releases on ASF mirrors
clean up older releases stored in https://dist.apache.org/repos/dist/release/incubator/mxnet/ and https://dist.apache.org/repos/dist/dev/incubator/mxnet/
Delete old releases from ASF mirrors (assuming new release version is 1.1.0 and the old one is 1.0.0# checkout apache release repo svn co https://dist.apache.org/repos/dist/release/incubator/mxnet apache-mxnet-release cd apache-mxnet-release # remove the previous release folder svn rm 1.0.0 svn commit -m 'commit message' # checkout apache dev repo svn co https://dist.apache.org/repos/dist/dev/incubator/mxnet apache-mxnet-dev cd apache-mxnet-dev # remove the previous release candidate folders svn rm 1.1.0.rc* svn commit -m 'commit message'
Enjoy an adult beverage (or bubble tea) of your choice, and congratulations on making a MXNet release.
The Release Checklist Template
For Every Release you must use the following checklist to ensure that all tasks happen in a timely manner -
In case you need to update this list, edit the original spreadsheet
Task # | Task | Owner | Relative Date | Absolute Date |
PreReqs for Release Start: | PM | |||
1 | Finalize the Release Date | PM | T-15 | |
2 | High Level List of Features and artifact specs | PM | T-15 | |
3 | Prepare Release Notes - draft 1 | PM | T-15 | |
4 | Inform the community | ReleaseLead | T-15 | |
5 | PR to update the Website into master/RB | WebsiteLead | T-14 | |
6 | PR to update the Docs into master/RB | DocsLead | T-14 | |
7 | PR to update the versions into master/RB | ReleaseLead | T-14 | |
8 | Validate License Headers and top Level LICENSE file | ReleaseLead | T-14 | |
9 | Validate/update submodules | ReleaseLead | T-14 | |
10 | Stabilize the code for CI to pass | ReleaseLead | T-14 | |
11 | Merge all necessary PRs into master | Community | T-13 | |
12 | Code Freeze and Release Start: Cut the Release Branch | ReleaseLead | T-10 | |
13 | Finalize the Release Notes based on PRs that got in - final draft | PM | T-10 | |
14 | PR to update the NEWS and README into the RB | ReleaseLead | T-9 | |
15 | Validate the docs build locally by checking release-specific docs like pip install, etc. | DocsLead | T-9 | |
16 | Test part 1: Run the unit Tests on the Release Branch | ReleaseLead | T-8 | |
17 | Test part 2: Run the Nightly Tests | ReleaseLead | T-8 | |
18 | Create the Github Tag for the rc0 | ReleaseLead | T-7 | |
19 | Create the src tar and sign, Upload the src tar | ReleaseLead | T-7 | |
20 | Validate the signatures | Release Lead | T-7 | |
21 | Clone svn repo and do a manual test | Release Lead | T-7 | |
Begin Apache Voting | ReleaseLead | T-7 | ||
22 | Start the vote on dev@ | ReleaseLead | ||
23 | Send out the results of the vote on dev@ | ReleaseLead | T-4 | |
24 | Revote if necessary (Steps 15-22) | ReleaseLead | Not Accounted For | |
25 | Start the vote on general@ | ReleaseLead | T-4 | |
26 | Send out the results of the vote on general@ | ReleaseLead | T-1 | |
End Apache Voting | ||||
27 | Create the final release tag on github | ReleaseLead | T-1 | |
28 | Rename, resign and upload the src tar to final dir | ReleaseLead | T-1 | |
29 | Update the website using tag | Website Lead | T-1 | |
30 | Release the official pip package | pip Lead | T-1 | |
31 | Release the official docker images | Docker Lead | T-1 | |
32 | After 24 hrs, validate the packages are uploaded | Release Lead | T | |
33 | Draft the offical announce email and review | Release Lead | T-1 | |
34 | Send out the email on announce@ | Release Lead | T | |
35 | Update the apache blog | Release Lead | T | |
36 | update the aws blog | PM | T | |
37 | send internal announcement | PM | T | |
38 | Update the version on master | Release Lead | T |
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 lead 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