Zulip server release checklist¶
This document has reminders of things one might forget to do when preparing a new release.
A week before the release¶
Upgrade all Python dependencies in
requirementsto latest upstream versions so they can burn in (use
pip list --outdated).
Update all the strings on Transifex and notify translators that they should translate the new strings to get them in for the next release.
changelog.mdwith major changes going into the release.
Create a burndown list of bugs that need to be fixed before we can release, and make sure all of them are being worked on.
Draft the release blog post (aka the release notes.)
Final release preparation¶
changelog.mdwith any changes since the last update, and with revisions from the draft blog post.
Download updated translation strings from Transifex and commit them.
build-release-tarballto generate a release tarball.
Test the new tarball extensively, both new install and upgrade from last release, on both Bionic and Focal.
Repeat until release is ready.
When near finished: move the blog post draft to Ghost. (For a draft in Dropbox Paper, use “··· > Download > Markdown” to get a pretty good markup conversion.) Proofread the post, especially for formatting.
Executing the release¶
Do final updates to
changelog.md, for any final changes and with any revisions from the draft blog post. (And the date!)
For major releases, update
API_FEATURE_LEVELto a feature level for the final release, and document a reserved range.
build-release-tarballto generate a final release tarball.
Post the release tarball on https://www.zulip.org/dist/releases/ : add the file, update the
zulip-server-latest.tar.gzsymlink, and add to SHA256SUMS.txt, using
Create a Git tag and push the tag.
Post the release on GitHub, using the text from
Update the Docker image and do a release of that.
Update the image of DigitalOcean one click app using Fabric and publish it to DO marketplace.
Publish the blog post.
Email zulip-announce, post to #announce, and send a tweet.
Push the release commit to master, if applicable (typically for a major release); otherwise, make sure any last changes make it back to master.
2.2.0+gitfollowing a 2.1.0 release, and make a Git tag named e.g.
2.2-devpointing to this update.
Consider removing a few old releases from ReadTheDocs.