This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Page tree
Skip to end of metadata
Go to start of metadata



Release manager and release co-manager (if manager is not a committer) are responsible for:

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

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

Use this script to get commits since a particular date
# 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"

Alternatively, you can use the script here to create groups of commits  based on commit comments.

Note: 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:

Community announcement email template

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.


[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 (this is ensured automatically by the PR validation check)
  • DISCLAIMER is correct, 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 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 by following previous version update PR ( Please update this wiki with latest version update PR to stay current.
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.

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): & See more detailed instructions on creating the key here: Instructions for updating the KEYS file can be found here: Note that you must use apache email instead of personal email for the key. 

Adding Keys
# checkout the apache mxnet repo
svn co 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.

  • To create a new major or minor branch use (replace v1.4.x with actual branch name): 
Git branch creation
# checkout clean master branch
git clone
cd incubator-mxnet
git branch v1.4.x
git push --set-upstream origin v1.4.x
  • 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: 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 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)

Nightly Tests

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



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 v.1.3.x job

Ensure that nightly tests are enabled for the target release branch, for example v.1.3.x NightlyTestsForBinariesv1.3.x NightlyTests

Ensure that release branch is in the daily reports (contact Marco de Abreu )

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.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 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 (question)

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:

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

Creating the src tar
git clone 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
find . -name ".git*" -print0 | xargs -0 rm -rf
brew install gnu-tar 
gtar -czvf apache-mxnet-src-0.12.0.rc0-incubating.tar.gz apache-mxnet-src-0.12.0.rc0-incubating


Details here:

Create SHA checksum: apache-mxnet-src-#.#.#.rc0-incubating.tar.gz.sha512

gpg --armor --output apache-mxnet-src-#.#.#-incubating.tar.gz.asc --detach-sig apache-mxnet-src-#.#.#-incubating.tar.gz
shasum -a 512 apache-mxnet-src-#.#.#-incubating.tar.gz > apache-mxnet-src-#.#.#-incubating.tar.gz.sha512

 Create a folder for this RC in the dist folder: #.#.#-incubating.RC0 folder 

Uploading to dist
# Checkout the Apache directory in Apache distribution SVN "dev" repo
$ svn co
# 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:

PGP signatures and SHA256 checksum verification

svn co && cd mxnet/#.#.#.rc0
brew install gpg coreutils
gpg --import ../KEYS
validate the signatures
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:

pip install --user -r ci/requirements.txt
ci/ -p ubuntu_gpu

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.


Follow the release process to build Scala/Java packages and include the stage repo links in the voting email:

Scala Release Process


Follow the release process to build Clojure packages and include the stage repo links in the voting email:

Clojure Release Process


Follow the release process to build R packages and include the stage repo links in the voting email:

R Release Process

2. Running the voting process for a release:

The full voting process consists of two phases: (1) vote on (3 days) (2) vote on (3 days). For full documentation refer to the Apache Voting Process.

Step 2.1. Vote on dev@ 

For the dev@ vote, there must be at least 3 binding +1 votes and more +1 votes than -1 votes. Once that quorum has been reached, the vote then moves onto the general@ vote.

To find out if the person has a binding vote visit:

Use the email template below to start the vote:

Opening vote email template

Subject: [VOTE] Release Apache MXNet (incubating) version $release.rc0

Dear MXNet community,

This is the vote to release Apache MXNet (incubating) version $release. Voting will start $start-date-time and close on $end-date-time, $time-zone.

Link to release notes:<tiny-link>

Link to release candidate:$release.rc0

Link to source and signatures on apache dist server:$release.rc0/

Link to scala packages on the staging repo:

* CPU<link>

* GPU<link>

Please remember to TEST first before voting accordingly:
+1 = approve
+0 = no opinion
-1 = disapprove (provide reason)

Best regards,

Step 2.2. Send out the vote results on dev@

Vote results email template

Subject: [RESULTS] [VOTE] Release Apache MXNet (incubating) version $release.rc0

Dear MXNet community,

I'm happy to announce the results of the vote.

This vote passes with <num> +1 votes (<num> binding) and no 0 or -1 votes.

+1 votes
* <name> / binding
* <name> / binding
* <name>
* <name>

0 votes
* No votes

-1 votes
* No votes

Vote thread can be found here [1]. The list of members can be found here [2].

I'll continue with the release process and the release announcement will follow in the next few days.

Best regards,


Step 2.3. Triage issues and re-vote 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 & 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.

Cancel vote template

Subject: [CANCELLED] [VOTE] Release Apache MXNet (incubating) version $release.rc0

Dear MXNet community,

We are cancelling this vote because:


We will address the issues and send out rc#+1 for another vote.

Best regards,

Step 2.4. Start a vote on general@

For the vote on general@, anyone can contribute a vote, but only "Incubator PMC" (IPMC) votes are binding.
To pass, there must be 3 binding +1 votes and more +1 votes than -1 votes.

In ASF, votes are open "at least" 72hrs (3 days). If you don't get enough number of binding votes within that time, you cannot close the voting deadline. You need to extend it.

Send out a notice to vote with the template below.
To get the fingerprint of your keys, run `gpg2 --list-keys --fingerprint`

Vote on @general email template

Subject: [VOTE] Release Apache MXNet (incubating) version $release.rc0

Dear community,

This is a call for a releasing Apache MXNet (incubating) #.#.#, release
candidate #.

Apache MXNet (incubating) community has voted and approved the release.

Vote thread:

Result thread:

The source tarball, including signatures, digests, etc. can be found at:

The tag to be voted upon is #########:

The release hash is #########:

Release artifacts are signed with the following key:

KEYS file available:

For information about the contents of this release, see:
<link to release notes>

The vote will be open for 72 hours.

[ ] +1 release this package as #########
[ ] +0 no opinion
[ ] -1 do not release this package because...

Best regards,

Step 2.5: Send out the vote results on general@

Send out an email on general@ in the same voting thread which you sent in previous step to summarize the result.

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 “<major>.<minor>.<patch>”

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 -

This process needs to change ->

Rename and Resign the RC to create GA
# 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
# Step 5: Move from dev to release
svn mv --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) -

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

  1. Add the new installation version on the install page: 

2. Add news about the new release. See this example: docs/_static/mxnet-theme/index.html.

3. Add download links to the install archives. See this example: docs/install/ Make sure to use the Apache distro servers. 

4. Update the pip package table: and on the install/ page.

This has a sketch file that can be updated to generate a new png image. Because this file is live and pulled from the web-data repo, you need to submit a PR to this repo with the new image. It is recommended that you add a new one with the version name. Then in your PR for the html updates, you refer to this specific new image, rather than updating the one that is used in production.

5. Test the build.

  • Run make html from the docs folder while on your edit branch and make sure the changes look good. At this point you can submit your PR.
  • While the PR is clearing CI, you can also test the publish job. This job happens every 6 hours, but it is good to make sure it's going to work once your PR gets merged.
  • Run the following from the docs/build_version_doc/ folder, but update it to include the new release's branch and name:
    ./ "v1.4.x;v1.3.x;v1.2.0;v1.1.0;v1.0.0;v0.12.0;v0.11.0;master" "1.4.0;1.3.1;1.2.1;1.1.0;1.0.0;0.12.1;0.11.0;master"
  • Then run the following to update the html and navigation. Make sure you add the new release version in the first parameter. Also update the last parameter to be the public IP of your staging web server. Publish the output of docs/build_version_doc/VersionedWeb to your staging server. For more details refer to building the production website.
    ./ "1.4.0;1.3.1;1.2.1;1.1.0;1.0.0;0.12.1;0.11.0;master" master

6. (This step requires CI access. Ask on Slack for assistance if you don't have access.) Configure the Jenkins website publishing job.

Go to 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 There can be a delay due to some edge caching with Apache infra. The restricted-website-build job also runs four times a day.

3.3. Update & on the MXNet master branch

Can happen after the announcement.

3.4. Review the announcement email content on before sending the announcement.

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

In order to get write access to, one need to first register on and ask Henri ( 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 email to the mailing list.

Follow instructions from here:

There must be a link in the announcement to the downloads page, not to the dyn/closer page. Downloads must be mirrored from the official Apache distribution site, not from github or other site. e.g. "A Link to the"

Send an email to and with the subject: [ANNOUNCE] Apache MXNet <release number> Release and a body along the lines of:

Subject: [ANNOUNCE] Release Apache MXNet (incubating) version $release

Dear all,

The Apache MXNet (incubating) community is happy to announce Apache MXNet (incubating) version ##.#.#!

( ## if applicable ## )

Release blog post:

( ## -- if applicable -- ## )

Apache MXNet (incubating) is a deep learning framework designed for both efficiency and flexibility. It allows you to mix symbolic and imperative programming to maximize efficiency and productivity.

( ## for patch releases ## )

1.3.1 is a maintenance release incorporating important bug fixes and important performance improvements.

( ## -- for patch releases -- ## )

A full list of the changes in this release can be found in the release notes:

A link to the download can be found here:

If you prefer to build from source and experiment with various compile-time configuration options, use this link to get the instructions:

Or you can download and play with MXNet easily using one of the options below:

1. The Pip packages can be found here:

2. The Docker Images can be found here:

Links in Maven to the published Scala packages:;quick~org.apache.mxnet

and to the experimental Clojure packages:

The Docker images:

The Pip package:

The Release Tag:

MXNet Resources
- Our discussion forum (
- MXNet user mailing list (
- MXNet dev mailing list (
- StackOverflow mxnet tag (
- MXNet website (
- Github issues (
- Wiki (

Attend one of the regular user groups meetings:

For more information on Apache MXNet (incubating), please see:

Best regards,
Apache MXNet (incubating) Team



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.

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. 

3.7. Bump up the versions on the master  

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 and

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 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 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 #TaskOwnerRelative DateAbsolute Date

PreReqs for Release Start:PM

1Finalize the Release DatePMT-15
2High Level List of Features and artifact specsPMT-15
3Prepare Release Notes - draft 1PMT-15
4Inform the communityReleaseLeadT-15
5PR to update the Website into master/RBWebsiteLeadT-14
6PR to update the Docs into master/RBDocsLeadT-14
7PR to update the versions into master/RBReleaseLeadT-14
8Validate License Headers and top Level LICENSE fileReleaseLeadT-14
9Validate/update submodulesReleaseLeadT-14
10Stabilize the code for CI to passReleaseLeadT-14
11Merge all necessary PRs into masterCommunityT-13

12Code Freeze and Release Start: Cut the Release BranchReleaseLeadT-10
13Finalize the Release Notes based on PRs that got in - final draftPMT-10
14PR to update the NEWS and README into the RBReleaseLeadT-9
15Validate the docs build locally by checking release-specific docs like pip install, etc.DocsLeadT-9
16Test part 1: Run the unit Tests on the Release BranchReleaseLeadT-8
17Test part 2: Run the Nightly TestsReleaseLeadT-8
18Create the Github Tag for the rc0ReleaseLeadT-7
19Create the src tar and sign, Upload the src tarReleaseLeadT-7
20Validate the signaturesRelease LeadT-7
21Clone svn repo and do a manual testRelease LeadT-7
22Update version number in Travis CI used for Scala BuildRelease LeadT-7

Begin Apache VotingReleaseLeadT-7
23Start the vote on dev@ReleaseLead

24Send out the results of the vote on dev@ReleaseLeadT-4
25Revote if necessary (Steps 15-22)ReleaseLeadNot Accounted For
26Start the vote on general@ReleaseLeadT-4
27Send out the results of the vote on general@ReleaseLeadT-1

End Apache Voting

28Create the final release tag on githubReleaseLeadT-1
29Rename, resign and upload the src tar to final dirReleaseLeadT-1
30Update the website using tagWebsite LeadT-1
31Release the official pip packagepip LeadT-1
32Release the official docker imagesDocker LeadT-1
33After 24 hrs, validate the packages are uploadedRelease LeadT
34Draft the offical announce email and reviewRelease LeadT-1
35Send out the email on announce@Release LeadT
36Update the apache blogRelease LeadT
37update the aws blogPMT
38send internal announcementPMT
39Update the version on masterRelease LeadT

Notes for reference


   - 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:
   - Release artifacts must include disclaimer in the release artifacts

   - The Incubator PMC expects the source releases to be staged on so that
   they can easily be moved to the release location via svn mv   (
   - After graduating, RC’s go into
   and official releases go into

   - Apache Press Team []
   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
      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:

   - Release should include:
      - LICENSE
      - NOTICE - attribution notices

   - 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?

   - 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.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, SHOULD be linked
      into web of trust
      - Keys MUST be RSA & 4096 bits

   - Apache RAT can assist in checking license compliance
   - Eventually we should set up a build system to sign our releases with
   cryptographic signatures. For now we’ll do it manually.

   - Create a signature and sign releases as mentioned above

  • No labels