2021-05-05 01:39:27 +02:00
|
|
|
# Release lifecycle
|
|
|
|
|
|
2021-05-06 03:24:17 +02:00
|
|
|
This page details the release lifecycle for the Zulip server and
|
|
|
|
|
client-apps, well as our policies around backwards-compatibility and
|
|
|
|
|
security support policies. In short:
|
|
|
|
|
|
2021-08-20 21:45:39 +02:00
|
|
|
- We recommend always running the latest releases of the Zulip clients
|
2021-05-06 03:24:17 +02:00
|
|
|
and servers. Server upgrades are designed to Just Work; mobile and
|
|
|
|
|
desktop client apps update automatically.
|
2021-08-20 21:45:39 +02:00
|
|
|
- The server and client apps are backwards and forwards compatible
|
2021-05-06 03:24:17 +02:00
|
|
|
across a wide range of versions. So while it's important to upgrade
|
|
|
|
|
the server to get security updates, bug fixes, and new features, the
|
|
|
|
|
mobile and desktop apps will continue working for at least 18 months
|
|
|
|
|
if you don't do so.
|
2021-08-20 21:45:39 +02:00
|
|
|
- New server releases are announced via the low-traffic
|
2021-05-06 03:24:17 +02:00
|
|
|
[zulip-announce email
|
2021-10-15 00:37:27 +02:00
|
|
|
list](https://groups.google.com/g/zulip-announce). We
|
2021-05-06 03:24:17 +02:00
|
|
|
highly recommend subscribing so that you are notified about new
|
|
|
|
|
security releases.
|
2021-08-20 21:45:39 +02:00
|
|
|
- Zulip Cloud runs the branch that will become the next major
|
2021-05-14 00:16:30 +02:00
|
|
|
server/web app release, so it is always "newer" than the latest
|
2021-05-06 03:24:17 +02:00
|
|
|
stable release.
|
2021-05-05 01:39:27 +02:00
|
|
|
|
2021-05-14 00:16:30 +02:00
|
|
|
## Server and web app
|
2021-05-05 01:39:27 +02:00
|
|
|
|
2021-05-14 00:16:30 +02:00
|
|
|
The Zulip server and web app are developed together in the [Zulip
|
2021-05-05 01:39:27 +02:00
|
|
|
server repository][zulip-server].
|
|
|
|
|
|
|
|
|
|
### Stable releases
|
|
|
|
|
|
2021-08-20 21:45:39 +02:00
|
|
|
- Zulip Server **stable releases**, such as Zulip 4.5.
|
2021-05-05 01:39:27 +02:00
|
|
|
Organizations self-hosting Zulip primarily use stable releases.
|
2021-08-20 21:45:39 +02:00
|
|
|
- The numbering scheme is simple: the first digit indicates the major
|
2021-08-20 21:53:28 +02:00
|
|
|
release series (which we'll refer to as "4.x"). (Before Zulip 3.0,
|
2021-05-05 01:39:27 +02:00
|
|
|
Zulip versions had another digit, e.g. 1.9.2 was a bug fix release
|
|
|
|
|
in the Zulip 1.9.x major release series).
|
2021-08-20 21:45:39 +02:00
|
|
|
- [New major releases][blog-major-releases], like Zulip 4.0, are
|
2021-05-05 01:39:27 +02:00
|
|
|
published every 3-6 months, and contain hundreds of features, bug
|
|
|
|
|
fixes, and improvements to Zulip's internals.
|
2021-08-20 21:45:39 +02:00
|
|
|
- New maintenance releases, like 4.3, are published roughly once a
|
2021-05-05 01:39:27 +02:00
|
|
|
month. Maintenance releases are designed to have no risky changes
|
2021-05-06 03:24:17 +02:00
|
|
|
and be easy to reverse, to minimize stress for administrators. When
|
|
|
|
|
upgrading to a new major release series, We recommend always
|
|
|
|
|
upgrading to the latest maintenance release in that series, so that
|
|
|
|
|
you use the latest version of the upgrade code.
|
docs: Consistently say "18 months" on compatibility, no specific version numbers.
Previously I've wanted to have this page spell out the concrete
version number that our clients support, rather than the policy we
use for determining that version number, because that's the sort of
question that I feel like as a user I'd want a straight answer to
and would be annoyed if I couldn't get one.
But as the text stands, it's come to look more like it's the policy
(something that's heavyweight to change) than like the value that
the policy currently happens to work out to. Also, because this page
is kind of chaotically organized (and fixing that is a bigger yak
than I want to shave right now), it repeats the 18-month rule in
three separate places and the current value (version 4.0) is in
a fourth separate place, so it looks internally inconsistent.
Let's therefore take a different tack: like in those other three
spots on this page, state just the policy instead of the value it
currently works out to; but also add a link to help the reader
pin down for themselves what value that does work out to.
This also means we no longer need to update this page as old releases
age and that value advances.
Also fix a typo, and cut the reference to working degraded on
older releases. Starting earlier this year we finally started
hard-refusing such connections:
https://github.com/zulip/zulip-mobile/issues/5102
https://github.com/zulip/zulip-mobile/pull/5633
(which was because there were some swathes of compatibility code
that we could only cut if we completely broke the handling of
ancient servers, and so we preferred to have the app communicate
that break clearly up front.)
2023-08-18 02:44:31 +02:00
|
|
|
- For the dates of past stable releases,
|
|
|
|
|
[see the Zulip blog][blog-releases].
|
2021-05-05 01:39:27 +02:00
|
|
|
|
2021-05-14 00:16:30 +02:00
|
|
|
Starting with Zulip 4.0, the Zulip web app displays the current server
|
2021-08-20 21:53:28 +02:00
|
|
|
version in the gear menu. With older releases, the server version is
|
2021-05-05 01:39:27 +02:00
|
|
|
available [via the API](https://zulip.com/api/get-server-settings).
|
|
|
|
|
|
|
|
|
|
This ReadTheDocs documentation has a widget in the lower-left corner
|
|
|
|
|
that lets you view the documentation for other versions. Other
|
|
|
|
|
documentation, like our [Help Center](https://zulip.com/help/), [API
|
|
|
|
|
documentation](https://zulip.com/api/), and [Integrations
|
|
|
|
|
documentation](https://zulip.com/integrations/), are distributed with
|
|
|
|
|
the Zulip server itself (E.g. `https://zulip.example.com/help/`).
|
|
|
|
|
|
docs: Consistently say "18 months" on compatibility, no specific version numbers.
Previously I've wanted to have this page spell out the concrete
version number that our clients support, rather than the policy we
use for determining that version number, because that's the sort of
question that I feel like as a user I'd want a straight answer to
and would be annoyed if I couldn't get one.
But as the text stands, it's come to look more like it's the policy
(something that's heavyweight to change) than like the value that
the policy currently happens to work out to. Also, because this page
is kind of chaotically organized (and fixing that is a bigger yak
than I want to shave right now), it repeats the 18-month rule in
three separate places and the current value (version 4.0) is in
a fourth separate place, so it looks internally inconsistent.
Let's therefore take a different tack: like in those other three
spots on this page, state just the policy instead of the value it
currently works out to; but also add a link to help the reader
pin down for themselves what value that does work out to.
This also means we no longer need to update this page as old releases
age and that value advances.
Also fix a typo, and cut the reference to working degraded on
older releases. Starting earlier this year we finally started
hard-refusing such connections:
https://github.com/zulip/zulip-mobile/issues/5102
https://github.com/zulip/zulip-mobile/pull/5633
(which was because there were some swathes of compatibility code
that we could only cut if we completely broke the handling of
ancient servers, and so we preferred to have the app communicate
that break clearly up front.)
2023-08-18 02:44:31 +02:00
|
|
|
[blog-major-releases]: https://blog.zulip.com/tag/major-releases/
|
|
|
|
|
[blog-releases]: https://blog.zulip.com/tag/release-announcements/
|
|
|
|
|
|
2021-05-05 01:39:27 +02:00
|
|
|
### Git versions
|
|
|
|
|
|
|
|
|
|
Many Zulip servers run versions from Git that have not been published
|
|
|
|
|
in a stable release.
|
|
|
|
|
|
2023-05-15 20:46:06 +02:00
|
|
|
- [Zulip Cloud](https://zulip.com) runs the `zulip-cloud-current`
|
|
|
|
|
branch; this the `main` branch, with some cherry-picked bug fixes,
|
|
|
|
|
but delayed somewhat. It is usually one to two weeks behind `main`,
|
|
|
|
|
depending on the complexity of recent major UI or internals changes
|
|
|
|
|
that we'd like to bake longer on chat.zulip.org before exposing them
|
|
|
|
|
to the full Zulip Cloud userbase.
|
2021-08-20 21:45:39 +02:00
|
|
|
- [chat.zulip.org][chat-zulip-org], the bleeding-edge server for the
|
2021-09-01 03:13:20 +02:00
|
|
|
Zulip development community, is upgraded to `main` several times
|
2021-08-20 21:53:28 +02:00
|
|
|
every week. We also often "test deploy" changes not yet in `main`
|
2021-05-05 01:39:27 +02:00
|
|
|
to chat.zulip.org to facilitate design feedback.
|
2021-08-20 21:45:39 +02:00
|
|
|
- We maintain Git branches with names like `4.x` containing backported
|
2021-09-01 03:13:20 +02:00
|
|
|
commits from `main` that we plan to include in the next maintenance
|
2022-01-05 03:22:30 +01:00
|
|
|
release. Self-hosters can [upgrade][upgrade-from-git] to these
|
2021-05-05 01:39:27 +02:00
|
|
|
stable release branches to get bug fixes staged for the next stable
|
|
|
|
|
release (which is very useful when you reported a bug whose fix we
|
2021-05-06 03:24:17 +02:00
|
|
|
choose to backport). We support these branches as though they were a
|
|
|
|
|
stable release.
|
2021-08-20 21:45:39 +02:00
|
|
|
- Self-hosters who want new features not yet present in a major
|
2021-09-01 03:13:20 +02:00
|
|
|
release can [upgrade to `main`][upgrading-to-main] or run [a fork
|
2021-05-05 01:39:27 +02:00
|
|
|
of Zulip][fork-zulip].
|
|
|
|
|
|
|
|
|
|
### Compatibility and upgrading
|
|
|
|
|
|
|
|
|
|
A Zulip design goal is for there never to be a reason to run an old
|
|
|
|
|
version of Zulip. We work extremely hard to make sure Zulip is stable
|
|
|
|
|
for self-hosters, has no regressions, and that the [Zulip upgrade
|
2023-01-17 04:33:42 +01:00
|
|
|
process](../production/upgrade.md) Just Works.
|
2021-05-05 01:39:27 +02:00
|
|
|
|
docs: Consistently say "18 months" on compatibility, no specific version numbers.
Previously I've wanted to have this page spell out the concrete
version number that our clients support, rather than the policy we
use for determining that version number, because that's the sort of
question that I feel like as a user I'd want a straight answer to
and would be annoyed if I couldn't get one.
But as the text stands, it's come to look more like it's the policy
(something that's heavyweight to change) than like the value that
the policy currently happens to work out to. Also, because this page
is kind of chaotically organized (and fixing that is a bigger yak
than I want to shave right now), it repeats the 18-month rule in
three separate places and the current value (version 4.0) is in
a fourth separate place, so it looks internally inconsistent.
Let's therefore take a different tack: like in those other three
spots on this page, state just the policy instead of the value it
currently works out to; but also add a link to help the reader
pin down for themselves what value that does work out to.
This also means we no longer need to update this page as old releases
age and that value advances.
Also fix a typo, and cut the reference to working degraded on
older releases. Starting earlier this year we finally started
hard-refusing such connections:
https://github.com/zulip/zulip-mobile/issues/5102
https://github.com/zulip/zulip-mobile/pull/5633
(which was because there were some swathes of compatibility code
that we could only cut if we completely broke the handling of
ancient servers, and so we preferred to have the app communicate
that break clearly up front.)
2023-08-18 02:44:31 +02:00
|
|
|
The Zulip server and client apps are all carefully engineered to
|
2021-08-20 21:53:28 +02:00
|
|
|
ensure compatibility with old versions. In particular:
|
2021-05-05 01:39:27 +02:00
|
|
|
|
2021-08-20 21:45:39 +02:00
|
|
|
- The Zulip mobile and desktop apps maintain backwards-compatibility
|
docs: Consistently say "18 months" on compatibility, no specific version numbers.
Previously I've wanted to have this page spell out the concrete
version number that our clients support, rather than the policy we
use for determining that version number, because that's the sort of
question that I feel like as a user I'd want a straight answer to
and would be annoyed if I couldn't get one.
But as the text stands, it's come to look more like it's the policy
(something that's heavyweight to change) than like the value that
the policy currently happens to work out to. Also, because this page
is kind of chaotically organized (and fixing that is a bigger yak
than I want to shave right now), it repeats the 18-month rule in
three separate places and the current value (version 4.0) is in
a fourth separate place, so it looks internally inconsistent.
Let's therefore take a different tack: like in those other three
spots on this page, state just the policy instead of the value it
currently works out to; but also add a link to help the reader
pin down for themselves what value that does work out to.
This also means we no longer need to update this page as old releases
age and that value advances.
Also fix a typo, and cut the reference to working degraded on
older releases. Starting earlier this year we finally started
hard-refusing such connections:
https://github.com/zulip/zulip-mobile/issues/5102
https://github.com/zulip/zulip-mobile/pull/5633
(which was because there were some swathes of compatibility code
that we could only cut if we completely broke the handling of
ancient servers, and so we preferred to have the app communicate
that break clearly up front.)
2023-08-18 02:44:31 +02:00
|
|
|
code to support any Zulip server version from the last 18 months.
|
2021-08-20 21:45:39 +02:00
|
|
|
- Zulip maintains an [API changelog](https://zulip.com/api/changelog)
|
2021-05-05 01:39:27 +02:00
|
|
|
detailing all changes to the API to make it easy for client
|
|
|
|
|
developers to do this correctly.
|
2021-08-20 21:45:39 +02:00
|
|
|
- The Zulip server preserves backwards-compatibility in its API to
|
2021-05-05 01:39:27 +02:00
|
|
|
support versions of the mobile and desktop apps released in roughly
|
|
|
|
|
the last year. Because these clients auto-update, generally there
|
|
|
|
|
are only a handful of active clients left by the time we desupport a
|
|
|
|
|
version.
|
|
|
|
|
|
|
|
|
|
As a result, we generally do not backport changes to previous stable
|
|
|
|
|
release series except in rare cases involving a security issue or
|
|
|
|
|
critical bug just after publishing a major release.
|
|
|
|
|
|
2023-01-17 04:33:42 +01:00
|
|
|
[upgrade-from-git]: ../production/upgrade.md#upgrading-from-a-git-repository
|
2021-05-05 01:39:27 +02:00
|
|
|
|
|
|
|
|
### Security releases
|
|
|
|
|
|
|
|
|
|
When we discover a security issue in Zulip, we publish a security and
|
|
|
|
|
bug fix release, transparently documenting the issue(s) using the
|
|
|
|
|
industry-standard [CVE advisory process](https://cve.mitre.org/).
|
|
|
|
|
|
|
|
|
|
When new security releases are published, we simultaneously publish
|
2021-09-01 00:15:31 +02:00
|
|
|
the fixes to the `main` and stable release branches (E.g. `4.x`), so
|
2021-05-05 01:39:27 +02:00
|
|
|
that anyone using those branches can immediately upgrade as well.
|
|
|
|
|
|
|
|
|
|
See also our [security model][security-model] documentation.
|
|
|
|
|
|
|
|
|
|
[security-model]: ../production/security-model.md
|
|
|
|
|
|
|
|
|
|
### Upgrade nag
|
|
|
|
|
|
2021-05-14 00:16:30 +02:00
|
|
|
Starting with Zulip 4.0, the Zulip web app will display a banner
|
2021-05-05 01:39:27 +02:00
|
|
|
warning users of a server running a Zulip release that is more than 18
|
|
|
|
|
months old. We do this for a few reasons:
|
|
|
|
|
|
2021-08-20 21:45:39 +02:00
|
|
|
- It is unlikely that a server of that age is not vulnerable to
|
2021-05-05 01:39:27 +02:00
|
|
|
a security bug in Zulip or one of its dependencies.
|
2021-08-20 21:45:39 +02:00
|
|
|
- The Zulip mobile and desktop apps are only guaranteed to support
|
2021-05-05 01:39:27 +02:00
|
|
|
server versions less than 18 months old.
|
|
|
|
|
|
|
|
|
|
The nag will appear only to organization administrators starting a
|
|
|
|
|
month before the deadline; after that, it will appear for all users on
|
|
|
|
|
the server.
|
|
|
|
|
|
|
|
|
|
You can adjust the deadline for your installation by setting e.g.
|
|
|
|
|
`SERVER_UPGRADE_NAG_DEADLINE_DAYS = 30 * 21` in
|
|
|
|
|
`/etc/zulip/settings.py` and then [restarting the server](../production/settings.md).
|
|
|
|
|
|
|
|
|
|
### Operating system support
|
|
|
|
|
|
|
|
|
|
For platforms we support, like Debian and Ubuntu, Zulip aims to
|
|
|
|
|
support all versions of the upstream operating systems that are fully
|
2021-08-20 21:53:28 +02:00
|
|
|
supported by the vendor. We document how to correctly [upgrade the
|
2021-05-05 01:39:27 +02:00
|
|
|
operating system][os-upgrade] for a Zulip server, including how to
|
|
|
|
|
correctly chain upgrades when the latest Zulip release no longer
|
|
|
|
|
supports your OS.
|
|
|
|
|
|
|
|
|
|
Note that we consider [Ubuntu interim releases][ubuntu-release-cycle],
|
|
|
|
|
which only have 8 months of security support, to be betas, not
|
|
|
|
|
releases, and do not support them in production.
|
|
|
|
|
|
|
|
|
|
[ubuntu-release-cycle]: https://ubuntu.com/about/release-cycle
|
|
|
|
|
|
|
|
|
|
### Server roadmap
|
|
|
|
|
|
|
|
|
|
The Zulip server project uses several GitHub labels to structure
|
|
|
|
|
communication within the project about priorities:
|
|
|
|
|
|
2021-08-20 21:45:39 +02:00
|
|
|
- The [high priority][label-high] label tags issues that we consider
|
2021-05-05 01:39:27 +02:00
|
|
|
important. This label is meant to be a determination of importance
|
|
|
|
|
that can be done quickly and then used as an input to planning
|
|
|
|
|
processes.
|
2021-08-20 21:45:39 +02:00
|
|
|
- The [release goal][label-release-goal] label is used for work that
|
2021-05-05 01:39:27 +02:00
|
|
|
we hope to include in the next major release. The related [post
|
|
|
|
|
release][label-post-release] label is used to track work we want to
|
|
|
|
|
focus on shortly after the next major release.
|
|
|
|
|
|
|
|
|
|
The Zulip community feels strongly that all the little issues are, in
|
|
|
|
|
aggregate, just as important as the big things. Most resolved issues
|
|
|
|
|
do not have any of these priority labels.
|
|
|
|
|
|
2023-06-12 14:51:03 +02:00
|
|
|
We welcome participation from our user community in influencing the Zulip
|
|
|
|
|
roadmap. If a bug or missing feature is causing significant pain for you, we'd
|
|
|
|
|
love to hear from you, either in
|
2021-12-09 20:15:18 +01:00
|
|
|
[chat.zulip.org](https://zulip.com/development-community/) or on the relevant
|
2023-06-12 14:51:03 +02:00
|
|
|
GitHub issue. Please an include an explanation of your use case: such details
|
|
|
|
|
can be extremely helpful in designing appropriately general solutions, and also
|
|
|
|
|
helps us identify cases where an existing solution can solve your problem. See
|
|
|
|
|
our guides for [reporting bugs](../contributing/reporting-bugs.md) and [giving
|
|
|
|
|
feedback](../contributing/contributing.md#user-feedback) for more details.
|
2021-05-05 01:39:27 +02:00
|
|
|
|
|
|
|
|
## Client apps
|
|
|
|
|
|
|
|
|
|
Zulip's client apps officially support all Zulip server versions (and
|
|
|
|
|
Git commits) released in the previous 18 months, matching the behavior
|
|
|
|
|
of our [upgrade nag](#upgrade-nag).
|
|
|
|
|
|
2021-08-20 21:45:39 +02:00
|
|
|
- The Zulip mobile apps release new versions from the development
|
2021-05-05 01:39:27 +02:00
|
|
|
branch frequently (usually every couple weeks). Except when fixing a
|
|
|
|
|
critical bug, releases are first published to our [beta
|
|
|
|
|
channels][mobile-beta].
|
|
|
|
|
|
2021-08-20 21:45:39 +02:00
|
|
|
- The Zulip desktop apps are implemented in [Electron][electron], the
|
2021-05-05 01:39:27 +02:00
|
|
|
browser-based desktop application framework used by essentially all
|
|
|
|
|
modern chat applications. The Zulip UI in these apps is served from
|
|
|
|
|
the Zulip server (and thus can vary between tabs when it is
|
|
|
|
|
connected to organizations hosted by different servers).
|
|
|
|
|
|
|
|
|
|
The desktop apps automatically update soon after each new
|
2021-05-06 03:24:17 +02:00
|
|
|
release. Because Zulip's desktop apps are implemented in Electron
|
2021-05-05 01:39:27 +02:00
|
|
|
and thus contain a Chromium browser, security-conscious users should
|
2021-05-06 03:24:17 +02:00
|
|
|
leave automatic updates enabled or otherwise arrange to promptly
|
|
|
|
|
upgrade all users after a new security release.
|
2021-05-05 01:39:27 +02:00
|
|
|
|
|
|
|
|
New desktop app releases rarely contain new features, because the
|
2021-05-14 00:16:30 +02:00
|
|
|
desktop app tab inherits its features from the Zulip server/web app.
|
2021-05-05 01:39:27 +02:00
|
|
|
However, it is important to upgrade because they often contain
|
|
|
|
|
important security or OS compatibility fixes from the upstream
|
|
|
|
|
Chromium project.
|
|
|
|
|
|
|
|
|
|
The Zulip server supports blocking access or displaying a warning to
|
|
|
|
|
users attempting to access the server with extremely old or known
|
|
|
|
|
insecure versions of the Zulip desktop and mobile apps, with an error
|
|
|
|
|
message telling the user to upgrade.
|
|
|
|
|
|
|
|
|
|
## API bindings
|
|
|
|
|
|
|
|
|
|
The Zulip API bindings and related projects maintained by the Zulip
|
|
|
|
|
core community, like the Python and JavaScript bindings, are released
|
|
|
|
|
independently as needed.
|
|
|
|
|
|
|
|
|
|
[electron]: https://www.electronjs.org/
|
2023-01-17 03:02:58 +01:00
|
|
|
[upgrading-to-main]: ../production/modify.md#upgrading-to-main
|
2023-01-17 04:33:42 +01:00
|
|
|
[os-upgrade]: ../production/upgrade.md#upgrading-the-operating-system
|
2021-12-09 20:15:18 +01:00
|
|
|
[chat-zulip-org]: https://zulip.com/development-community/
|
2023-01-17 03:02:58 +01:00
|
|
|
[fork-zulip]: ../production/modify.md
|
2021-05-05 01:39:27 +02:00
|
|
|
[zulip-server]: https://github.com/zulip/zulip
|
|
|
|
|
[mobile-beta]: https://github.com/zulip/zulip-mobile#using-the-beta
|
2021-08-20 22:54:08 +02:00
|
|
|
[label-blocker]: https://github.com/zulip/zulip/issues?q=is%3Aissue+is%3Aopen+label%3A%22priority%3A+blocker%22
|
|
|
|
|
[label-high]: https://github.com/zulip/zulip/issues?q=is%3Aissue+is%3Aopen+label%3A%22priority%3A+high%22
|
|
|
|
|
[label-release-goal]: https://github.com/zulip/zulip/issues?q=is%3Aissue+is%3Aopen+label%3A%22release+goal%22
|
|
|
|
|
[label-post-release]: https://github.com/zulip/zulip/issues?q=is%3Aissue+is%3Aopen+label%3A%22post+release%22
|
