Apereo CAS 发布策略深度解析：SECURITY、PATCH、FEATURE 与 MAJOR 四类版本的演进规则与生命周期-平芜编程栈

后端
认证鉴权
单点登录

【免费下载链接】cas

Apereo CAS - Identity & Single Sign On for all earthlings and beyond.

项目地址：https://gitcode.com/gh_mirrors/ca/cas

本文以 Apereo CAS 官方发布策略（Release Policy）为核心，逐类解析 SECURITY、PATCH、FEATURE、MAJOR 四种版本类型各自允许容纳的变更范围、对采用者（overlay 项目）的升级影响，以及第三方依赖升级在各类型中的准入条件；并结合当前仓库的 gradle.properties、发布脚本 ci/release.sh 与维护策略文档 docs/cas-server-documentation/developer/Maintenance-Policy.md，说明这些策略在版本命名、发布流程与版本生命周期上的具体落地方式。读完本文，你将能够准确判断一次升级（如8.0.x到8.0.x+1、或8.0.x到8.1.x）会带来多大的兼容风险，并理解 CAS 安全版本的两周宽限期与滚动前滚（roll-forward）机制。

一、发布策略总览：变更被如何权衡

CAS 官方在 Release-Policy.md 中开宗明义：CAS 通过一套发布策略来决定不同版本的发布可以容纳哪些类型的变更，以及各条开发线（development line）如何管理。任何新改进、修复、增强与变更，都会被放在这套策略的标尺下权衡，再决定归入哪个未来的版本。

该策略同时给出了一条对采用者极为重要的告诫（原文以醒目警告框呈现）：尽量避免修改 CAS 软件内部实现。对 CAS 内部机制改动越多、承载的"定制化"用例越深，后续版本升级就越痛苦——你会迎面撞上配置变更与 API 变更。官方的建议是：把你的用例与社区讨论、将变更贡献回上游，让自己的部署只做这些变更的"消费者"（consumer），而不是"所有者"（owner），从而把维护负担从一身扛下转为社区共担。

这一告诫与后文的版本分级直接呼应：版本类型越低（SECURITY/PATCH），承诺的兼容性越强，对"未动过内部代码"的部署而言就越接近"即插即用"的升级。

当前仓库的构建元数据印证了这套策略的现实载体。gradle.properties 中定义了发布所需的全部平台元数据，例如：

group=org.apereo.cas version=8.1.0-SNAPSHOT projectLicenseName=The Apache Software License, Version 2.0

其中version=8.1.0-SNAPSHOT正处于 FEATURE 线的开发态——按后文的语义，8.1.x是从8.0.x演进而来的 MINOR 线，-SNAPSHOT后缀表明这是尚未切版的在研版本。

二、四种版本类型的精确定义与升级承诺

2.1 SECURITY 安全版本：针对已确认漏洞的最小变更

官方定义：安全版本是对某次发布所做的"关键性最小变更"，用于处置一个严重的、已确认的安全问题。版本号规则是：2.5.0.1就是2.5.0加上一个修补漏洞所需的最小改动。官方强烈敦促所有采用者尽快升级到 SECURITY 版本。

对采用者的兼容性承诺与依赖规则：

CAS overlay 应能不改动直接构建（除非发布说明中明确要求并特别标注）；
安全版本中不升级任何第三方库，除非存在扎实证据，证明并确有必要付出升级某个包的工作量（官方将该细节指向安全漏洞响应文档，本仓库中为 docs/cas-server-documentation/developer/Sec-Vuln-Response.md）。

漏洞响应文档对"最小变更"做了进一步的量化表述：安全修复应当"surgical"（外科手术式），补丁版本应是升级时的 drop-in replacement——通常不需要改动平台要求与版本、应用注册记录、界面、CAS 配置、日志语义、构建流水线等。对大多数部署而言，升级安全版本更接近"升级并验证"，而不是"取消你的周末"。唯一严重例外是：你修改过 CAS 服务器内部组件、且你的改动直接覆盖了上游的修复。

该文档还规定了安全版本独有的发布节奏——两周宽限期（grace period）：安全版本发布后，二进制包立即可用，但源码补丁、commit 与发布标签在宽限期结束前保持私有。以文档示例为例：

版本	发布日期	宽限期结束	二进制发布可用	源码可用	GitHub 通知
`6.6.1.X`	7 月 10 日	7 月 24 日	7 月 10 日	7 月 24 日	7 月 24 日

由此产生两个对采用者很实际的推论：其一，从源码构建 CAS 的团队在安全版本事件中将至少落后两周，因为源码层变更只会在宽限期结束后出现在仓库中；其二，安全版本（以及所有类型的 CAS 版本）永远滚动前滚（roll forward）——6.6.1.X+1包含6.6.1.X、6.6.1.X-1、6.6.1.X-2及其之前发布中的全部变更，安全版本从不是孤立产生的。

另外两点边界规则值得记住：CAS 项目不为安全问题申请或提供 CVE（需要 CVE 的组织须自行办理）；CAS 也不提供安全赏金。

2.2 PATCH 补丁版本：同一 MINOR 线内绝对向后兼容

官方定义：PATCH 是保守的渐进式改进，包含 bug 修复、增强与新特性，且与同一 MINOR 发布线内先前的 PATCH 版本绝对向后兼容。例如2.4.15是2.4.14、2.4.13、2.4.12等的直接替换品（drop-in replacement）。

采用者可以预期：主要 API、集成点、默认行为与整体配置大体不变；CAS overlay 只需极少甚至无需改动即可重新构建（除非发布说明与变更日志中特别标注）。依赖规则与 SECURITY 相同：PATCH 版本中不升级第三方库，除非有扎实证据证明确有必要。

2.3 FEATURE 特性版本：允许破坏兼容的"进化式"变更

官方定义：FEATURE 是"进化式"（evolutionary）的渐进改进，包含所有 PATCH 级的改进，外加那些若不加就会破坏向后兼容或改变默认行为的修复与增强。典型例子是从3.4.x过渡到3.5.x。

采用者可以预期：API、集成点、默认行为与整体配置需要中等程度的变更；沿同一条 MINOR 开发线看，CAS 服务器代码在版本之间"看起来大体相同，但带有清晰的中等幅度进化式变化"。FEATURE 版本可能带有主题或聚焦点以协调开发。对 overlay 的直接影响：可能需要小到中等的改动，某些 API 可能变更或已被弃用，默认行为与配置可能改变。

FEATURE 类型有两条重要的边界约束：

对外契约 API 在 FEATURE 版本之间保持不变。文档特别强调：内部实现 API 可能变化，但 CAS 面向集成方的公共 API（本仓库中对应api/顶层目录下的各cas-server-core-api-*模块，如 api/cas-server-core-api-authentication）在 FEATURE 版本之间不受影响。从 settings.gradle 的结构可以印证这一分层：api:、core:、support:、webapp:四类模块分别对应公共 API 层、核心实现层、功能支持层与应用层，"API 稳定、实现可演进"的策略正是建立在这种模块划分之上。
第三方库升级在 FEATURE 版本中是允许的，但导致平台要求（Java、操作系统、服务器容器）变化的库升级会被忽略。

2.4 MAJOR 主版本：允许平台变更的"革命式"重构

官方定义：MAJOR 是"革命式"（revolutionary）变更，容纳全面的架构、思路与实现变更。典型例子是从3.5.x过渡到4.0.x。

采用者可以预期：API、默认行为与配置可能发生重大变化；overlay 可能需要重大修改乃至彻底重构；沿该版本线看，CAS 服务器代码可能面目一新，集成点可能需要返工。依赖规则最宽松：第三方库升级完全允许，包括可能导致平台要求（Java、OS、服务器容器）升级的变更。

从源码结构看，当前仓库 gradle.properties 中sourceCompatibility=25、targetCompatibility=25，即 MAJOR 线允许的平台要求变化已经在构建配置中体现为对 JDK 25 的绑定——这正是 MAJOR 类型相对于 FEATURE 类型在依赖策略上唯一的额外自由度。

2.5 四类版本对照速查

维度	SECURITY	PATCH	FEATURE	MAJOR
定位	已确认安全问题的最小变更	同一 MINOR 线内保守的增量改进	进化式增量改进，可含破坏兼容的变更	革命式架构/实现重构
版本示例	`2.5.0`→`2.5.0.1`	`2.4.14`→`2.4.15`	`3.4.x`→`3.5.x`	`3.5.x`→`4.0.x`
向后兼容	是（drop-in）	绝对向后兼容（同 MINOR 线）	部分破坏兼容	允许重大破坏
overlay 构建影响	基本无需改动	极少至无需改动	小到中等改动，API 或弃用/变更	可能需重大修改甚至重构
第三方库升级	原则上禁止（需扎实证据）	原则上禁止（需扎实证据）	允许（平台要求变化则忽略）	允许（含平台要求变化）
升级紧迫度	尽快	按发布计划	按发布计划	按发布计划

三、发布节奏与版本生命周期

3.1 发布计划与"时间驱动"的版本

Release-Policy 与 Maintenance-Policy.md 均将发布排期指向项目的 milestone 计划。维护策略文档对"稳定性"给出了坦率说明：CAS 的版本是严格基于时间的（time-based）发布，不以特定基准、统计指标或功能/缺陷完成度为排期依据；要建立对一个版本的信心，应尽早用 RC 或后续 snapshot 进行实验。

3.2 维护窗口：6 个月常规维护 + 6 个月 SPM

维护策略文档规定（以"CAS Release"指任一功能发布线，如8.0.x）：

采用者可以预期一个 CAS 版本自原始发布之日起被维护 6 个月，期间包含 bug 修复、安全补丁与一般性维护，并按发布计划提供 PATCH 版本；
之后维护严格限定为安全补丁与漏洞修复，再持续 6 个月，即进入安全补丁模式（Security-Patch Mode，SPM）；
版本的实际寿命可以超过一年，由 CAS PMC 与社区在资源、人力与经费允许时决定。

文档给出了当前的 EOL（End-of-Life）时间表，未列出的发布一律视为已 EOL：

Release	SPM 开始日期	完全 EOL 日期
`8.0.x`	2027 年 1 月 17 日	2027 年 7 月 17 日
`7.3.x`	2026 年 6 月 30 日	2026 年 12 月 31 日

EOL 意味着项目停止接受、追加和发布该版本线的任何类型补丁；EOL 版本的文档维护与托管也会停止，如需文档可自行从 CAS 代码库中取得页面源码自行渲染托管。

3.3 SPM 阶段与安全报告的边界

一旦某条发布线进入 SPM，其版本线与相关 milestone 会公开关闭；补丁与贡献必须经由为安全问题设计的指定渠道沟通与上报，并按安全漏洞响应文档的流程审阅。报告必须信息充分、可复现。同时，漏洞响应文档明确：上报前请确认受影响的 CAS 版本线仍在维护期内，EOL 版本不会获得项目方任何进一步更新；对 EOL 版本，项目也不评估、不验证、不修补、不测试，最佳路径是升级到仍在社区维护的版本。

另外，维护策略对 LTS 也给出了明确态度：基于志愿者可用性与经费状况，CAS 项目无法在可实践、可持续的意义上提供 LTS 版本；有 LTS 需求的组织应与项目接洽讨论。

四、策略如何落到构建与发布流程中

版本策略最终要由发布流程执行。Release-Process.md 描述了两种执行路径（本地执行与 GitHub Actions 派发，后者为推荐方式），而仓库中的 ci/release.sh 是本地路径的实际脚本。把脚本行为与前文策略对照，可以看到策略的几处硬性约束都写进了代码：

1. 版本号必须与 SNAPSHOT 状态严格匹配。脚本会先从 gradle.properties 解析version，然后强制校验：

版本含SNAPSHOT时只能走snapshot分支（发布到publishAggregationToCentralSnapshots，即 Maven Central 快照仓库）；
非 SNAPSHOT 版本进入publish分支，且发布前先执行./gradlew verifyDependencyVersions校验依赖版本，校验失败立即中止——这是"依赖升级受版本类型约束"这一策略在流水线中的落点；
版本号带v前缀会直接报错退出，防止把 tag 误当版本号。

2. RC 与正式版的差异化处理。脚本在创建 GitHub Release 时按版本后缀区分：

if [[ "${casVersion}" == *-RC* ]]; then releaseFlags="--prerelease" # RC 版本标记为 pre-release else releaseFlags="--latest" # 正式版本标记为 latest fi

这与维护策略中"尽早实验 RC/snapshot 以建立版本信心"的建议形成闭环：RC 在 GitHub 上明确以 pre-release 身份存在，正式版本则以 latest 标识，采用者据此选择升级时机。

3. 发布后自动回到 SNAPSHOT 开发态。发布成功后，脚本用sed将gradle.properties中的版本改写为--next-version指定的下一个开发版本（如发布8.0.0-RC1后写入8.0.1-SNAPSHOT），提交并自动开 PR。这解释了为什么仓库中看到的版本号几乎总是-SNAPSHOT形态：仓库主干永远是"下一个版本"的开发态，正式版本号只以 tag 形式存在。

4. 发布产物与聚合发布。非 SNAPSHOT 发布默认执行publishAggregationToCentralPortal（Sonatype Central Portal 聚合发布）；--split模式下则拆分为cas-webapp-tomcat.zip、cas-webapp-jetty.zip、cas-webapp-config-server.zip等独立包并逐个上传——对应仓库 webapp/ 下的cas-server-webapp-tomcat、cas-server-webapp-jetty等可部署模块。此外，脚本会为每个版本创建v<version>的 git tag、生成含贡献者清单与 RC 链接的 release notes，并关闭对应 milestone；--private模式则跳过打 tag 与 GitHub Release 创建，仅做私有发布。

5. 签名与凭证。本地发布需要预先在~/.gradle/gradle.properties配置 GPG 签名信息（signing.keyId、signing.password、signing.secretKeyRingFile），并通过REPOSITORY_USER/REPOSITORY_PWD环境变量提供仓库凭证；脚本在启动时若发现两个凭证缺失会直接退出。GitHub Actions 路径则免去这些本地配置，直接派发Releaseworkflow 并提供版本号与下一开发版本即可。

五、采用者视角：如何依据策略做升级决策

综合 Release-Policy、Maintenance-Policy 与 Sec-Vuln-Response 三份文档，可以把升级决策归纳为四条规则：

收到 SECURITY 版本通告时，优先升级。它承诺 drop-in 兼容（前提是你没有覆盖上游被修复的内部组件），二进制发布即刻可用；若你依赖源码构建，需自行评估"落后两周"的窗口风险。
PATCH 升级视为零风险替换。同一 MINOR 线内的 PATCH 绝对向后兼容，overlay 应无需改动即可重建。
FEATURE 升级前审计 API 使用面。内部实现 API 可能变化或弃用、默认行为与配置可能改变；但面向集成方的公共 API（api/层模块）在同一 MINOR 线之间保持不变，可作为兼容性的锚点。
确认版本线仍在维护窗口内再投入。对照 EOL 时间表（本文写作时8.0.x于 2027 年 7 月 17 日 EOL，7.3.x于 2026 年 12 月 31 日 EOL），EOL 版本不再获得任何类型补丁；对第三方依赖 CVE 的告警，官方建议的做法是升级 CAS 版本或在本地构建中自行替换库，而非期待 PATCH/SECURITY 版本代劳。

最后一句贯穿全文的建议（即开篇"Stop Coding"警告）在升级决策中同样成立：保持 overlay 对 CAS 内部实现零侵入，是四种版本类型中兼容性承诺全部兑现的前提。