mirror of https://github.com/zulip/zulip.git synced 2025-11-02 13:03:29 +00:00

Files

Greg Price a70816c76e docs: Stop linking to specific versions of our docs entirely.

We started doing this for install docs in de2a2d0df, because `latest`
wasn't suitable and because I didn't know about readthedocs's `stable`
feature.  The result has been that even with a checklist item, we
don't reliably update the link.

Instead, use the special `stable` version identifier on readthedocs to
link automatically to the highest version it knows about.

2018-04-25 14:36:56 -07:00

2.4 KiB

Raw Blame History

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 requirements to 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.
Update changelog.md with 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

Update changelog.md with any changes since the last update, and with revisions from the draft blog post.
Download updated translation strings from Transifex and commit them.
Use build-release-tarball to generate a release tarball.
Test the new tarball extensively, both new install and upgrade from last release, on both Trusty and Xenial.
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!)
Update ZULIP_VERSION in version.py.
Update version and/or release in docs/conf.py (ReadTheDocs meta tags). Leave "+git" off.
Use build-release-tarball to 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.gz symlink, and add to SHA256SUMS.txt.
Create a Git tag and push the tag.
Post the release on GitHub, using the text from changelog.md.
Publish the blog post.
Email zulip-announce, and send a tweet.
For a major release: submit blog post to aggregators.

Post-release

Push the release commit to master, if applicable (typically for a major release); otherwise, make sure any last changes make it back to master.
Update ZULIP_VERSION in version.py, and release and version in docs/conf.py, to e.g. 1.6.0+git.
Consider removing a few old releases from ReadTheDocs.

2.4 KiB Raw Blame History