What we must do better with next release:

IssueAction ItemAssigneeStatus
Apache Rat license check tool was broken

Fix RAT licenese check in trunk.

Update Readme file to mention new steps



Running nightly tests on release branch. Get access to configure jobsNeeded CI configuration changes. Anton configured nightly jobs to run on release branches. Previously it used to only run on master branch. Backward Compatibility checker is currently restricted job. So, need to run it manually or update the job to not be restricted,



Automate/ write a script to update all files with version number for mxnet + packagesRight now, you have to manually update all the files with new version number in MXNet repo. Need to automate the process.RoshaniTODO
Release artifacts to be tested were not uploaded to release tag before sending email on dev listUpdated release process document to include this step. Need to include link to source and dist packages on apache server. Update release process doc for this too.



Creating artifacts right now is manual process, can be turned into a easy scriptWrite a script to creating artifacts, validate release package, test package steps Release Process#Step1.9.Createartifactsforthereleaseandpushtothedistfolder
Build Scala packages and publish on mavenWe did not wait for building/publishing Scala packages to start voting. Need to give more time after creating RC so that we can include testing for scala/R packages in voting. Updated document to keep time for building packages.RoshaniDone
Release blocker issues. Lot of back and forth for including fixes for issues and due to difference in opinions

We need to have some kind of bar to decide what should a release blocker and what should not.

Releases are expensive in terms of time and efforts. There needs to be a high and more objective bar on what qualifies as a release blocker to make sure we are not setting precedence for a lot of release blockers in future.
I think a release blocker is justified only if there is a serious bug discovered in one of the features included in the release or if there is a regression.

TVM submodule history rewrite issue

Due to security issue, MXNet community members from Amazon requested tvm community for a complete history rewrite. This was a breaking change for all the release branches of MXNet. Although tvm community made clear the implication of history rewrite, the MXNet community members failed to raise it on dev@ or take other preventive action. It caused multiples issues getting created in MXNet repo and website build failed on all branches.

For any potential breaking changes, community members should make best effort in making people aware, through means such as dev@ list.

Release blogpost on medium

For every release, we check with product manager Sukwon to see if we need to publish a blog post for the particular release. We do consider time for apache blog post. But for 1.3 release, we didn't consider time to publish medium blog post (this can be significantly more as it goes through multiple reviews from Apps team) while planning release, as this step was not mentioned in the release process.

Updated release process doc to check with product manager first if we want to publish a medium blog post.

Release PIP package with buggy openblas versionMXNet PIP packages were published with buggy openblas version. Upgraded openblas dependency to 0.3.3 to fix the issue and published post-release packages.ShengDone
Windows PIP packageWith every release, we publish PIP packages for Linux, Mac on the same day. Windows PIP package is often published after announcing the release. For 1.3, we tried to reach out to Windows PIP package maintainer to publish the PIP package before release. Delayed release announcements due to this issue. Going forward, we want to publish PIP packages for all the platforms before announcements.

  • No labels