关于版本发布
版本号如何读、有哪些发布类型、版本如何升级 — 一文讲清。
26R3.1 是怎么读出来的
平台版本号采用四段格式 {Year}R{Release}.{Patch}.{Maintenance}，另有与版本号解耦的 build 号。
「26R3」表示 2026 年第 3 个正式版本，如 26R3.1 的「26R3」。
正式版本内的小版本位，如 26R3.1 的「.1」。
维护发布序号，按 scope 独立递增（如 26R3.1.46），不同 scope 的维护版本各自编号，故版本号并非严格时间顺序。
与版本号解耦的十进制数字串（如 Assembly 13258 / Platform 13250），由构建工件产出，供定位具体构建。
三类发布
按内容与节奏区分三类发布。
带来新功能与修复的正式版本，如 26R3.1。每个公开发布都有对应的发布说明：新功能、已修复问题与已知问题。
针对已发布版本的小修复，版本号 Maintenance 位递增。
正式发布前，在沙盒上运行新版本以验证配置与流程的窗口。详见「预发布 FAQ」。
一个版本如何发布
版本经由发布列车（ADCV）统一编排，关键节点如下。
功能与配置在发布列车（ADCV）上收敛，形成目标版本。
切出版本并打标（如 v26R3.1-13258），版本号与 build 号从此确定。
产出镜像与 CLI / 演示制品，供环境部署与客户端使用。
沙盒可先行验证，生产 Vault 由平台统一编排升级。
版本由平台统一管理
以下规则保证升级可预期、可追溯。
生产 Vault 的升级由平台统一编排，不能提前升级、延后升级、跳过或降级。
目标版本等于源版本：直接复制；目标更高：复制后前向升级；目标更低：拒绝（不会误降级）。
仅配置载荷：复制配置，不含业务数据、文档与用户；含数据载荷：源沙盒的完整拷贝（含用户与归属）。
沙盒与源互为独立实例：源的后续变更不影响沙盒，沙盒的变更也不回流源。
升级期间的几点建议
正式升级前，先在沙盒上运行新版本，验证既有配置与关键流程。
避免配置变更与版本升级相互影响。
升级前查看当前版本的已知问题页。