企业官网建设流程全解析

Zulip 版本发布生命周期（Release Lifecycle）全解析：稳定版、Git 分支与客户端兼容策略

【免费下载链接】zulipZulip server and web application. Open-source team chat that helps teams stay productive and focused.项目地址: https://gitcode.com/GitHub_Trending/zu/zulip

本指南以 Zulip 开源仓库的官方文档 docs/overview/release-lifecycle.md 为核心骨架，结合 version.py、zerver/lib/compatibility.py、zproject/default_settings.py 等源码，系统讲解 Zulip 服务器与各客户端 App 的版本发布节奏、Git 分支演进、版本兼容矩阵与升级提示机制。读完本文，你将掌握：如何判断自己运行的 Zulip 版本、如何选择稳定版或 Git 分支进行升级、客户端与服务器的兼容期限如何计算，以及如何通过配置调整"升级提醒（upgrade nag）"的触发时间。

版本发布概述

Zulip 服务器与 Web 应用在同一个代码仓库中协同开发，二者共享同一套版本号。当前仓库对应的开发版本为12.0-dev+git，而version.py中声明的LATEST_MAJOR_VERSION = "12.0"、LATEST_RELEASE_VERSION = "12.2"，即为当前最新稳定发布系列与最新维护版本号。

Zulip 官方强烈建议自托管组织运行最新稳定版。官方为稳定版投入了大量精力确保其无回归，并保证 升级流程 开箱即用。新版本发布消息通过低流量的 zulip-announce 邮件列表公布，尤其建议订阅以便第一时间获知安全版本发布通知。

服务器与 Web 应用版本

稳定版（Stable releases）

稳定版是自托管 Zulip 组织的主力选择，例如当前最新的{{ LATEST_RELEASE_VERSION }}（即 12.2）。其版本号规则如下：

• 首位数字代表大版本系列（major release series）：例如9.4属于 9.x 系列，12.2属于 12.x 系列。这一点在官方文档中以专门注记强调，是理解 Zulip 版本体系的基础。
• 主版本（Major releases）：如 Zulip 9.0、Zulip 12.0，每年发布两次，包含数百项新特性、缺陷修复与内部改进。
• 维护版本（Maintenance releases）：如 9.4、12.2，大约每月发布一次，设计目标是不包含有风险变更、易于回滚，以最大限度降低管理员在升级时的压力。

官方给出的升级建议是：升级到新的主版本系列时，始终升级到该系列中最新的维护版本，这样能够确保使用到最新版本的升级代码。

在 version.py 中可以看到这些常量在实际代码库中的落地：

LATEST_MAJOR_VERSION = "12.0" LATEST_RELEASE_VERSION = "12.2" LATEST_RELEASE_ANNOUNCEMENT = "https://blog.zulip.com/zulip-server-12-0"

安全版本（Security releases）

当发现 Zulip 的安全问题时，官方会发布一个同时包含安全修复与缺陷修复的版本，并通过业界标准的 CVE 公告流程透明地记录问题。

发布安全版本时，修复会同时提交到main分支和当前主版本系列的发布分支，因此无论你运行的是 Git 版本还是稳定版，都能及时获得修复。相关内容可进一步参考安全概述与 保护你的 Zulip 服务器指南。

Git 版本（Git versions）

许多 Zulip 服务器运行的版本来自 Git 仓库、尚未进入稳定版发布。官方维护了多条具有不同用途的分支：

• main分支：最新的开发主线，可通过upgrade-zulip-from-git main升级以获得最新变更，详见 升级到main。
• 9.x这类维护分支：包含从main回溯（backport）的提交，这些提交计划进入下一个维护版本。自托管用户可以升级到这些分支，提前获得已确定将进入下一个稳定版发布、但已回溯好的缺陷修复（当你上报的 bug 的修复被选中回溯时，这非常有用）。官方将这些分支视同稳定版一样提供支持。
• chat.zulip.org分支：Zulip 开发社区使用的服务器（chat.zulip.org）运行该分支，每周多次合并main的更新，并且经常"试部署"一些尚未进入main的变更以收集设计反馈。
• zulip-cloud-current分支：Zulip Cloud 云端服务运行该分支外加部分精选变更。该分支通常比main延迟一到两周，以便新变更在被部署到客户之前得到进一步验证。
• 自维护分支：你还可以在这些分支之上运行 Zulip 的 fork。

Git 分支的升级操作在 docs/production/upgrade.md#upgrading-from-a-git-repository 中有完整说明，对应命令为：

# 升级到官方发布版本 /home/zulip/deployments/current/scripts/upgrade-zulip-from-git 11.5 # 升级到维护分支 /home/zulip/deployments/current/scripts/upgrade-zulip-from-git 11.x # 升级到 Zulip Cloud 分支 /home/zulip/deployments/current/scripts/upgrade-zulip-from-git zulip-cloud-current # 升级到 main 分支 /home/zulip/deployments/current/scripts/upgrade-zulip-from-git main

我运行的是哪个版本？

Zulip Web 应用会在齿轮菜单（gear menu）中显示当前服务器版本；同时也可以通过 API 的server_settings端点获取。该端点在 zerver/views/auth.py 中实现（api_get_server_settings），其 OpenAPI 测试用例位于 zerver/openapi/python_examples.py，响应中即包含zulip_version字段。

与版本配套的文档

为了确保文档与你的服务器版本匹配，帮助中心、API 文档与集成文档都随 Zulip 服务器一同分发（例如https://zulip.example.com/help/）。此外，这份 ReadTheDocs 文档的左上角提供了版本切换小部件，可以查看其他版本的文档。

客户端 App

Zulip 官方客户端 App 支持过去 18 个月内发布的所有服务器版本，并且被设计为与"最老受支持服务器版本到当前main分支之间"的中间 Git 提交兼容。这意味着服务器管理员可以放心升级到 Git 版本而不会破坏客户端。

API 变更日志 与 tools/create-api-changelog，版本号中的API_FEATURE_LEVEL（当前为 511，见 version.py）由后者在 API 变更合入main时递增，作为客户端探测服务器 API 能力的重要依据。

移动端 App

移动端 App 从开发分支频繁发布新版本（通常每隔一两周）。除非是修复关键 bug，否则新版本会先发布到 beta 通道。移动端与桌面端 App 默认自动更新，除非用户主动关闭。

桌面端 App

桌面端 App 基于 Electron（几乎现代聊天应用通用的浏览器内核桌面框架）实现，其 UI 由 Zulip 服务器提供——因此同一个桌面 App 连接不同服务器托管的组织时，各标签页的界面可能不同。

桌面端 App 在新版本发布后会很快自动更新。由于界面能力继承自服务器/Web App，新桌面版本很少包含新功能；但升级依然重要，因为它通常包含来自上游 Chromium 项目的安全或操作系统兼容性修复。官方明确建议保持自动更新开启，或在安全版本发布后及时安排升级。

在源码层面，桌面端与移动端 App 的兼容门槛由 zerver/lib/compatibility.py 的is_outdated_desktop_app实现：低于DESKTOP_MINIMUM_VERSION（5.4.3）的版本将被服务器直接拒绝访问，介于最低版本与DESKTOP_WARNING_VERSION（5.9.3）之间的版本会显示升级警告横幅，而 4.0.0 之前的旧版（含已知安全问题的 2.3.82 及更老版本，且不会自动更新）会被判定为(insecure, banned, auto_update_broken)三元组全为 True。相关版本常量定义在 version.py。完整的判定逻辑测试位于 zerver/tests/test_compatibility.py。

终端 App

Zulip 终端 App（zulip-terminal，目前处于 beta 阶段）设计为支持与其他客户端相同的服务器版本范围。但官方不支持用旧版终端 App 连接最新 Zulip 服务器——这意味着终端 App 用户有时需要在服务器升级到新主版本后，同步升级到最新的终端 App 版本。

服务器与客户端兼容性策略

Zulip 的设计目标始终是"让用户可以随时运行最新服务器版本"。因此官方通常不会向之前的主版本系列回溯变更，除非出现两种情况：安全问题和主版本发布后不久发现的严重 bug。

服务器在 API 层面保持向后兼容，以支持过去 12 个月内发布的移动端与桌面端版本；由于这些客户端自动更新，在官方放弃对某版本的支持时，绝大多数活跃客户端早已完成升级。同时，官方客户端支持过去 18 个月内发布的所有服务器版本（对应约 540 天）。

升级提醒（Upgrade nag）

当服务器运行的版本超过 18 个月、不再受移动端与桌面端 App 官方支持时，Zulip Web 应用会显示横幅警告用户升级。提醒的节奏很讲究：

• 截止日期前一个月开始，仅组织管理员可见；
• 之后对所有用户可见。

可以调整提醒期限，例如在/etc/zulip/settings.py中设置：

SERVER_UPGRADE_NAG_DEADLINE_DAYS = 30 * 21

修改后需按 settings.md 的说明重启服务器。

⚠️警告：运行超过 18 个月的服务器极可能受 Zulip 自身或上游依赖中安全漏洞的影响。

源码级机制：SERVER_UPGRADE_NAG_DEADLINE_DAYS的默认值为30 * 18（540 天），定义于 zproject/default_settings.py。提醒判定逻辑在 zerver/lib/compatibility.py 的is_outdated_server中实现：

• 服务器"最后升级时间"取自部署目录时间戳（生产环境）或当前时间（开发环境），并与version.py文件自身的修改时间取较小者，用于识别"一年内升过级、但升到了超过一年老版本"的情况；
• 截止时间 = 该时间 +SERVER_UPGRADE_NAG_DEADLINE_DAYS天；
• 非管理员用户额外再加 30 天宽限（这正是"管理员提前一个月看到提醒"的实现）；
• 判定结果server_needs_upgrade通过 zerver/lib/events.py 写入注册事件状态，最终由前端 web/src/navbar_alerts.ts 渲染为导航栏告警，并在 web/templates/popovers/navbar/navbar_gear_menu_popover.hbs 的齿轮菜单中展示入口。

这一机制的单元测试位于 zerver/tests/test_home.py：测试通过@override_settings(SERVER_UPGRADE_NAG_DEADLINE_DAYS=365)将期限缩短，并分别验证了第 10 天（无人被提醒）、第 397 天（全员被提醒）、第 380 天（仅管理员被提醒）三种时间点下的行为，与文档描述完全吻合。

操作系统支持

对于官方支持的平台（如 Debian 和 Ubuntu），Zulip 旨在支持上游厂商仍在完整支持的所有系统版本。官方文档详细说明了如何为 Zulip 服务器正确 升级操作系统，包括当最新 Zulip 版本不再支持你的操作系统时，如何正确串联（chain）多次升级。

需要注意：Ubuntu 的临时版本（interim releases）只有 8 个月的安全支持，Zulip 将其视为beta 而非正式发布版，不提供生产环境支持。

API 绑定（API bindings）

Zulip API 绑定及相关项目（如 Python 与 JavaScript 绑定）按需独立发布，与服务器主版本节奏解耦。这与服务器/Web App 共享版本号的模式形成对比——客户端库可以更快地迭代，同时通过 API 向后兼容机制保持对多版本服务器的支持。

关键要点总结

对于 Zulip 管理员而言，理解这套生命周期模型的价值在于：稳定版优先、及时跟进安全版本、善用维护分支获取已确定修复、保持自动更新开启，并留意升级提醒的出现时机——这既是维持服务器安全的基本盘，也是与 Zulip 官方客户端生态保持长期兼容的前提。

【免费下载链接】zulipZulip server and web application. Open-source team chat that helps teams stay productive and focused.项目地址: https://gitcode.com/GitHub_Trending/zu/zulip