- 消息队列
- 流处理
- 后端
- 微服务
- 消息路由
【免费下载链接】pulsar
Apache Pulsar - distributed pub-sub messaging system
本文基于仓库内的 PIP-162: LTS Releases 提案展开，介绍 Apache Pulsar 引入「长期支持版本」（Long Term Supported，简称 LTS）的动机、版本认定流程、网站与发布目录的落地改造，并结合仓库内后续的 PIP-175、PIP-472 等提案，还原 LTS 机制在 Pulsar 版本生命周期中的实际演进。读完本文，你将理解 Pulsar 如何向用户明确「哪些版本长期受支持、支持到何时」，以及这一机制在源码仓库、版本命名与升级兼容性中的具体体现。
一、背景与动机：为什么 Pulsar 需要 LTS 版本
Pulsar 的社区开发节奏非常快，几乎每个版本都会引入新特性与行为变化。但并非所有用户都能跟随这一节奏频繁升级——生产环境中的升级涉及运维排期、兼容性回归测试、客户端与服务端联动等多重成本。
PIP-162 的出发点非常直接：
Some users of Pulsar cannot move as quickly as development does. In order to better support users we should declare certain release versions to be "Long Term Supported" orLTS.
提案给出的典型 LTS 触发场景是：下一个版本带来了环境级变化（environmental change），例如：
- JDK 版本升级：运行环境要求发生根本性变化。仓库中的 PIP-156: Build and Run Pulsar Server on Java 17 正是这类场景的实例——它把 Pulsar 服务端构建与运行的最低 Java 版本从 8/11 提升到 17，同时保留 Java 客户端仍以 Java 8 为最低运行时目标。对仍停留在旧 JDK 环境的用户而言，升级前需要一个「可以安全停留更久」的版本。
- 重大协议变更（major protocol change）：客户端与服务端之间的二进制协议、鉴权方式或管理接口发生不兼容变化，迫使所有客户端同步升级。
在这些情况下，把上一个版本正式声明为 LTS，意味着它会在相当长的时间窗口内持续获得维护（包括安全修复），让用户不必被迫立刻跟随升级。
二、LTS 版本认定流程：一周讨论 + 一周投票
PIP-162 的 Goal 部分给出了 LTS 认定的正式流程，这是整个提案最核心的制度设计：
- 讨论阶段：对每一个拟认定为 LTS 的候选版本，项目先在
dev@邮件列表（Apache Pulsar 开发者邮件列表）上发起至少一周的讨论； - 共识确认：若讨论达成正向共识（positive consensus）；
- 投票阶段：随后在
dev@邮件列表上发起为期一周的正式投票（vote）。
这一「先讨论、后投票」的两段式设计与 Pulsar 的 PIP 提案流程一脉相承。仓库中的 pip/README.md 详细描述了 Pulsar Improvement Proposal 的标准流程：
- 作者以
[DISCUSS] PIP-xxx: {PIP TITLE}为邮件主题发起讨论； - 讨论收敛后以
[VOTE] PIP-xxx: {PIP TITLE}发起投票； - 投票要求至少一个 binding 的 +1 票，且在无 binding -1 票的情况下满足惰性多数（lazy majority）原则。
LTS 认定复用同一套社区民主机制，确保了「哪个版本算 LTS」不是个人或少数维护者的主观决定，而是经过社区充分讨论与正式投票形成的公开承诺，用户可以从邮件列表档案中回溯每个 LTS 版本被认定的完整过程。
三、落地实现：网站信息与发布目录改造
PIP-162 明确要求把 LTS 信息固化到 Pulsar 官方网站，避免「口头承诺、难以查询」的局面。Implementation 部分列出的改动包括四项：
1. 新增lts_versions.json清单文件
在网站数据层新增lts_versions.json文件，记录所有 LTS 版本及其支持截止日期（supported through date）。这份机器可读的 JSON 是 LTS 信息的单一事实来源：
- 每个 LTS 版本对应一条记录，包含版本号与支持截止时间；
- 网站页面（下载页、版本历史页）都可以从这个文件渲染，保证信息一致；
- 机器可读格式也方便用户脚本化地检查「我当前使用的版本是否仍在支持窗口内」。
2. 更新 Releases 区块的下载页
下载页需要描述当前各 LTS 版本的状态，让用户一进入下载页就能判断：哪个版本是当前 LTS、各自支持到什么时候，从而做出「上新版本还是留在 LTS」的知情决策。
3. 在「Older Releases」区块标记 LTS 版本
历史版本列表（Older Releases）中需要明确标记出哪些版本属于 LTS。未标记时，用户面对一长串历史版本号往往无从判断哪些仍在维护；标记之后，即便某个 LTS 版本已不是最新版，用户也能一眼识别它仍处于受支持状态。
4. Apache 官方发布目录保留最新 LTS 版本
在 Apache 的官方发行物目录（svn.apache.org/dist/releases/pulsar，即 Apache 软件基金会对外提供二进制发行物的目录）中，最新一个 LTS 版本要一直保留在 releases 目录里，而不是像普通旧版本那样被归档到 archive 目录。
提案给出的具体例子：当 2.11.0 发布时，2.10.0 仍保留在 Apache Releases 目录中（而不是被移走）。这意味着：
- 从 Apache 主发行目录下载的用户始终能拿到最新 LTS 版本；
- 对于需要停留在 LTS 的用户，官方主目录就是稳定的下载来源，无需前往历史归档区寻找；
- 直到下一个 LTS 版本出现，旧 LTS 才会让出「目录常驻」的位置，形成平滑的交接。
四、LTS 机制在版本生命周期中的演进（PIP-175 的细化）
PIP-162 确立了「LTS 版本 + 社区认定流程」的框架，而仓库中紧随其后的 PIP-175 把这个机制进一步具体化为固定节奏的版本发布与支持窗口模型，可作为理解 PIP-162 实际运行方式的直接续篇：
- LTS 发布节奏：每18 个月发布一个 LTS 版本；日常特性版本保持每3 个月一个的现有节奏；
- LTS 版本标识：以
.0版本号标识，如3.0是 LTS、3.1/3.2是常规特性版、4.0又是 LTS。主版本号的递增不再承载「大特性/破坏性 API」的隐含意义，而只是标识该版本属于 LTS 类型； - LTS 支持窗口：LTS 版本提供24 个月的支持，安全补丁延长至36 个月；特性版本则仅提供 6 个月支持与安全补丁；
- 滚动支持范围：折算下来即「最近 2 个 LTS 版本 + 最近 2 个特性版本受支持，最近 3 个 LTS 版本 + 2 个特性版本可获得安全补丁」；
- 相邻 LTS 间可在线升降级：如
3.0 → 4.0 → 3.0、3.2 → 4.4 → 3.2均被保证可行，而3.2 → 5.0跨越两个 LTS 则不被保证——这一兼容性承诺让用户可以在相邻 LTS 之间从容迁移。
从这套细化模型可以看出，PIP-162 提出的lts_versions.json中「supported through date」字段，正是用来承载 PIP-175 定义的 24/36 个月窗口；两者共同构成了 Pulsar 面向用户的可查询、可预期的支持承诺。
五、被否决的替代方案（Rejected Alternatives）
PIP-162 明确记录了被否决的替代方案，帮助读者理解为何需要制度化 LTS：
被否决方案一：维持现状（aspirational approach）。此前的做法更多是「愿望式」的——社区希望大家长期使用某些版本，但没有明确宣告哪些版本是我们真正打算长期支持的。其问题在于：用户无法获得清晰的版本支持预期，也就无法据此制定升级规划。PIP-162 的 LTS 制度正是对这种模糊状态的纠正。
被否决方案二：从现有发布中挑选 LTS 候选。提案评估了当时已发布版本成为 LTS 的可行性，结论是：
- 唯一可行的候选是 2.7.4；
- 2.8 和 2.9 因存在特性不完整（feature incompleteness）问题，不适合作为 LTS——LTS 版本必须是一个「功能完整、可长期依赖」的稳定形态，特性未收尾的版本无法承担多年维护承诺。
这一评估从反面说明了 LTS 的准入门槛：并非所有历史版本都适合被追认为 LTS，只有功能完整、质量达标的版本才值得进入长期支持通道。
六、从仓库证据看 LTS 机制的实际落地
PIP-162 是一份流程与制度提案，其影响已沉淀在仓库的多个角落，可以从源码与文档层面交叉印证：
- 版本线规划：PIP-472 明确写道「Pulsar 5.0 是依据 PIP-162 的下一 LTS 版本线」，并选择在 5.0 LTS 分支切出之前完成
javax.*到jakarta.*的 API 迁移——因为一旦进入多年代维护的 LTS 窗口，破坏性变更的成本会急剧上升； - 命名与发布对齐：PIP-342 计划在4.0 LTS 版本中敲定命名方案，同样体现了「LTS 是重大决策落点」的社区共识；
- 规格文档约束：spec/scalable-topics/stability.md 中规定「每个新 MAJOR 版本对应一个新的 Pulsar LTS 版本」，且破坏性变更与弃用特性的移除只允许发生在 LTS 边界，禁止出现在中间版本——这保证了用户在 LTS 之间的升级路径中，被弃用特性与其替代品始终共存；
- 维护分支纪律：CONTRIBUTING.md 要求代码不能未经
dev@邮件列表讨论（通常还需正式投票）就合入 LTS/维护分支，与 PIP-162 的认定流程保持同一套社区治理逻辑； - LTS 生命周期与生态协同：PIP-421 在讨论 Java 17/21 升级时明确引用「Pulsar 的 LTS 版本获得 2~3 年支持」这一窗口，说明 LTS 机制已成为后续技术决策（如 JDK 升级）的既定前提。
这些证据表明：PIP-162 不只是「网站加个 JSON 文件」的表面改动，而是确立了贯穿版本命名、支持窗口、升级兼容、维护分支管理乃至 API 演进策略的长期制度。
七、总结
PIP-162 为 Apache Pulsar 引入了正式的 LTS 版本制度，其核心价值可以归纳为三点：
- 可预期的支持承诺：通过「一周讨论 + 一周投票」的社区流程认定 LTS 版本，并以
lts_versions.json记录每个 LTS 的支持截止日期，让用户明确知道哪些版本可以长期依赖； - 可追溯的版本状态：下载页、Older Releases 区块、Apache 官方发行目录三处联动，最新 LTS 版本始终可从主目录获取，历史 LTS 在列表中清晰标记；
- 可持续的演进框架：后续 PIP-175（18 个月 LTS 节奏、24/36 个月支持窗口、相邻 LTS 在线升级保证）与 PIP-472（5.0 LTS 承载重大 API 迁移）在 PIP-162 的框架上继续演进，使 LTS 成为 Pulsar 版本管理的事实标准。
对于在生产环境运行 Pulsar 的团队，理解这套机制意味着：选择 LTS 版本可以显著降低升级频率与升级风险；在面临 JDK 升级、协议变更等环境级变化时，LTS 是社区为你留出的「安全着陆区」。
相关文档索引
- PIP-162: LTS Releases（本文主体）
- PIP 提案流程与 PIP 列表
- PIP-175: 版本节奏与支持窗口模型
- PIP-156: Pulsar 服务端迁移至 Java 17（LTS 触发场景示例）
- PIP-472: 在 5.0 LTS 中完成 Jakarta API 迁移
- PIP-342: 命名方案在 4.0 LTS 落定
- PIP-421: LTS 支持窗口与 JDK 升级协同
- 可扩展主题规格：MAJOR 与 LTS 对齐约束
- 贡献指南：LTS/维护分支的合入门槛
- 消息队列
- 流处理
- 后端
- 微服务
- 消息路由
【免费下载链接】pulsar
Apache Pulsar - distributed pub-sub messaging system
相关推荐
Kubernetes LTS 工作组（WG LTS）归档文档解读：从“是否需要长期支持”到兼容版本机制落地
Kubernetes LTS 工作组（WG LTS）归档文档解读：从“是否需要长期支持”到兼容版本机制落地 导读 本文基于 Kubernetes 社区仓库中已归
开源治理文档研发协作node.bcrypt.js长期支持计划：LTS版本的安全维护周期
node.bcrypt.js长期支持计划：LTS版本的安全维护周期 密码安全是应用系统的基石，而Node.js生态中最受欢迎的密码哈希库node.bcrypt.
密码学Stanford CME 106速查表的多语言支持：全球工程师的学习利器
Stanford CME 106速查表的多语言支持：全球工程师的学习利器 想要快速掌握斯坦福大学CME 106概率与统计课程的核心概念吗？Stanford CM
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
 内部算法与 [[DefineOwnProperty]] 实现)
