日历版本是什么
日历版本（CalVer）用发布年月日构造版本号，如 2026.10、26.10.2，让「新旧」一眼可见。Ubuntu 的 24.04、pip 自 2025 年切换后的 25.x 都是典型例子。它的取舍很明确：顺序天然清晰，但不表达兼容性语义——升级判断需要额外约定或搭配补丁位规则。适合节奏固定、承诺宽松的产品线。
基本信息
| 适用平台 | 操作系统、开发工具、内部平台等节奏固定的产品 |
|---|---|
| 常见格式 | YYYY.MM、YY.MM.DD、YYYY.MINOR.PATCH |
| 优点 | 新旧直观、与发布节奏天然同步、时间线可读 |
| 代价 | 不表达兼容性，升级影响面需另用发布说明约定 |
| 与 semver 的关系 | 不冲突但不可互换：semver 的位置表兼容性，CalVer 的位置表时间，需要兼容判断时另立规则 |
典型使用场景
- 月度发车产品：到点发布、迟到等下月，版本号即日历
- 工具链年度版本：每年一个大版本（如某年 .1 到次年 .0）
- 内部平台迭代：团队对外只承诺「用月底的版本」这种粗粒度节奏
- 与 LTS 策略配合：周年版本做长期支持，中间版本滚动升级
- 文档与规范编号：发布日期即引用代号，讨论时无需换算
- 多产品对齐：全线产品统一按月份发布，集成测试窗口可提前规划
版本示例
版本示例
2026.10.0 2026 年 10 月首个正式版
26.10.2 简写年份的第 10 月第 2 次修订
2026.10.0-rc.1 候选版本，语义与 semver 预发布一致常见格式对照
| 格式 | 示例 | 注意 |
|---|---|---|
| YYYY.MM | 2026.10 | 月内多次发布无法区分，需补修订位 |
| YY.MM.PATCH | 26.10.2 | 两位年份跨世纪会有歧义，内部用足够 |
| YYYY.MM.DD | 2026.10.13 | 适合高频发布；同日内多版仍需补位 |
CalVer 常与「每月固定发车」配合：到点发车、赶不上的变更顺延下月，节奏可预期，也倒逼需求排队而不是无限拖期。
版本号应在构建时生成：由 CI 脚本取当前日期输出（如 date +%Y.%m 的结果），并固定时区，避免月末时区差异导致版本跳号。