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-devgit而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 文档的左上角提供了版本切换小部件可以查看其他版本的文档。客户端 AppZulip 官方客户端 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_VERSION5.4.3的版本将被服务器直接拒绝访问介于最低版本与DESKTOP_WARNING_VERSION5.9.3之间的版本会显示升级警告横幅而 4.0.0 之前的旧版含已知安全问题的 2.3.82 及更老版本且不会自动更新会被判定为(insecure, banned, auto_update_broken)三元组全为 True。相关版本常量定义在 version.py。完整的判定逻辑测试位于 zerver/tests/test_compatibility.py。终端 AppZulip 终端 Appzulip-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 * 18540 天定义于 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_DAYS365)将期限缩短并分别验证了第 10 天无人被提醒、第 397 天全员被提醒、第 380 天仅管理员被提醒三种时间点下的行为与文档描述完全吻合。操作系统支持对于官方支持的平台如 Debian 和 UbuntuZulip 旨在支持上游厂商仍在完整支持的所有系统版本。官方文档详细说明了如何为 Zulip 服务器正确 升级操作系统包括当最新 Zulip 版本不再支持你的操作系统时如何正确串联chain多次升级。需要注意Ubuntu 的临时版本interim releases只有 8 个月的安全支持Zulip 将其视为beta 而非正式发布版不提供生产环境支持。API 绑定API bindingsZulip API 绑定及相关项目如 Python 与 JavaScript 绑定按需独立发布与服务器主版本节奏解耦。这与服务器/Web App 共享版本号的模式形成对比——客户端库可以更快地迭代同时通过 API 向后兼容机制保持对多版本服务器的支持。关键要点总结主题核心结论依据稳定版节奏主版本每年 2 次维护版本约每月 1 次release-lifecycle.md升级建议升级到新系列时选该系列最新维护版本同上Git 分支main、9.x维护分支、chat.zulip.org、zulip-cloud-current各司其职同上客户端兼容官方客户端支持过去 18 个月的服务器版本同上服务器兼容API 向后兼容过去 12 个月的客户端同上升级提醒默认值SERVER_UPGRADE_NAG_DEADLINE_DAYS 30 * 18非管理员 30 天default_settings.py、compatibility.py桌面端版本门槛低于 5.4.3 拒绝访问低于 5.9.3 显示警告version.py当前版本常量LATEST_MAJOR_VERSION 12.0LATEST_RELEASE_VERSION 12.2version.py对于 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考