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
Major releases only (e.g. 4.0):
Upgrade all Python dependencies in
requirementsto latest upstream versions so they can burn in (use
pip list --outdated).
Upgrade all puppet dependencies in
Upgrade all puppet-installed dependencies (e.g. Smokescreen, go, etc) in
Merge draft updates to the changelog with changes since the last release. While doing so, take notes on things that might need follow-up work or documentation before we can happily advertise them in a release blog post.
TODO/compatibilitycomments for whether we can remove any backwards-compatibility code in this release.
Create a burn-down list of issues that need to be fixed before we can release, and make sure all of them are being worked on.
Draft the release blog post (a.k.a. the release notes) in Paper. In it, list the important changes in the release, from most to least notable.
Final release preparation
Update the Paper blog post draft with any new commits.
Major releases only: Download updated translation strings from Transifex and commit them.
build-release-tarballto generate a pre-release tarball.
Test the new tarball extensively, both new install and upgrade from last release, on Ubuntu 20.04 or 22.04.
Repeat until release is ready.
Send around the Paper blog post draft for review.
Move the blog post draft to Ghost:
Use “··· > Export > Markdown” to get a pretty good markdown conversion, then insert that as a Markdown block in Ghost.
Proofread, especially for formatting.
Tag the post with “Release announcements” first, then any other tags (e.g. “Security”).
Executing the release
Create the release commit, on
main(for major releases) or on the release branch (for minor releases):
Copy the Markdown release notes for the release into
Verify the changelog passes lint, and has the right release date.
Major releases only: Adjust the
changelog.mdheading to have the stable release series boilerplate.
Major releases only: Update
API_FEATURE_LEVELto a feature level for the final release, and document a reserved range.
tools/releasewith the release version.
Update the Docker image:
Commit the Docker updates:
Update the image in
docker-compose.yml, as well as the
Commit the Helm updates:
Add a new entry to
Update the docs by running
Build the image:
docker build . -t zulip/docker-zulip:4.11-0 --no-cache
Also tag it with
docker build . -t zulip/docker-zulip:latest
Push those tags:
docker push zulip/docker-zulip:4.11-0; docker push zulip/docker-zulip:latest
Push the commits to
Publish the blog post; check the box to “send by email.”
Announce the release, pointing to the blog post, via:
The DigitalOcean one-click image will report in an internal channel once it is built, and how to test it. Verify it, then publish it to DigitalOcean marketplace.
Major releases only:
Create a release branch (e.g.
On the release branch, update
version.pyto the present release with a
ZULIP_VERSIONto the future major release with a
5.0-dev+git. Make a Git tag for this update commit with a
5.0-dev. Push the tag to both zulip.git and zulip-internal.git to get a correct version number for future Cloud deployments.
Consider removing a few old releases from ReadTheDocs; we keep about two years of back-versions.
Update Transifex to add the new
4.xstyle release branch resources and archive the previous release branch’s resources with the “Translations can’t translate this resource” setting.
Add a new CI production upgrade target:
Build a docker image:
cd tools/ci && docker build . -f Dockerfile.prod --build-arg=BASE_IMAGE=zulip/ci:bullseye --build-arg=VERSION=5.0 --tag=zulip/ci:bullseye-5.0 && docker push zulip/ci:bullseye-5.0
Add a new line to the
Minor releases only (e.g. 3.2):
On the release branch, update
ZULIP_VERSIONto the present release with a
On main, update
LATEST_RELEASE_VERSIONwith the released version, as well as the changelog changes from the release branch.