日历化版本 1
1. 简介
CalVer 不是基于任意数字，而是基于项目发布日期的版本控制约定
版本随着时间的推移会变得更好。
对于维护者，版本使我们在不断扩大的生态系统中可以指定精确的依赖关系。对于卖家和推广者来说，项目的版本是一个品牌的活力部分。对我们所有人来说，版本使我们在升级到将来时可以参考过去。
不同的项目使用不同的系统命名版本，但是常见的实践已经浮现出来。例如，以点分隔的数字（例如：语义化版本 2.0.0）就是全部。另一种常见的版本模式包含一个基于时间的元素，通常是发布日期的一部分。
这种基于日期的方法被称为“日历化版本（Calendar Versioning）”，或者简称 CalVer。
2. 方案
有多种日历化版本方案，长期被各种大小项目使用。与其宣布某个方案为 CalVer，更重要的是要认识到每个方案的可行性并设计一个适合项目的方案。
2.1. 版本部分
主要（Major）：版本中的第一个数字。2 和 3 是 Python 的著名主要版本。主要部分是基于日历的最常见组件。
次要（Minor）：版本中的第二个数字。7 是 Python 的最受欢迎的次要版本。
微小（Micro）：版本中的第三个且通常是最终数字。有时称为 “补丁” 部分。
修饰符（Modifier）：可选的文本标记，例如 “dev”、“alpha”、“beta”、“rc1”，依此类推。
绝大多数现代版本标识符是由两个或三个数字段组成，以及可选的修饰符。通常建议不要使用四个数字段的版本。
2.2. 标准术语
如下面的 样例学习 所示，项目发现了不止一种有用的方法在版本中使用日期。 作为对比，CalVer 并未像 “语义化版本” 那样选择单一方案，而是引入了开发人员的标准术语：
YYYY：年份全称 - 2006、2016、2106
YY：年份缩写 - 6、16、106
0Y：以零填充的年份 - 06、16、106
MM：月份缩写 - 1、2 ... 11、12
0M：以零填充的月份 - 01、02 ... 11、12
WW：星期（自年初开始）- 1、2、33、52
0W：以零填充的星期 - 01、02、33、52
DD：日 - 1、2 ... 30、31
0D：以零填充的日 - 01、02 ... 30、31
请注意，传统的递增版本号是从 0 开始，而日期段是从 1 开始的，且年份缩写和以零填充的年份是相对于 2000 年。还请注意，星期的使用通常与月/日互斥。
假定采用 公历、UTC 的惯例也是如此。从技术上讲可以使用任何日历，只要提供的项目声明使用哪一个。
3. 样例学习
CalVer 有很多用户。考虑到知名度和使用案例的多样性选择以下项目。
3.1. 产品
| 产品 | CalVer 格式 | 例子 |
|---|---|---|
| Ubuntu | YY.0M |
4.10 - 17.04 |
| Microsoft Windows | YY/YYYY |
95, 98, 2000 |
| OpenSCAD | YYYY.0M |
2015.03 |
| JetBrains PyCharm | YYYY.MINOR.MICRO |
2017.1.2 |
| Unity | YYYY.MINOR.MICRO |
2019.2.2 |
| Slack for Mobile | YY.0M.MICRO |
19.08.10 |
| Tesla Firmware | YYYY.WW.MICRO |
2020.12.10 |
3.2. 标准
| 产品 | CalVer 格式 | 例子 |
|---|---|---|
| Ada | YY/YYYY |
83, 95, 2012 |
| C | YY |
89, 99, 11 |
| C++ | YY |
98, 03, 11, 14, 17 |
3.3. 库
| 产品 | CalVer 格式 | 例子 |
|---|---|---|
| Boltons | YY.MINOR.MICRO |
17.2.0 |
| Twisted | YY.MM.MICRO |
16.1.1 |
| certifi | YYYY.MM |
2016.4 |
| pytz | YY.MINOR.MICRO |
18.0 - 19.0.3 |
| pip | YY.MINOR.MICRO |
18.0 - 19.0.3 |
4. 何时使用？
如果你和你不认识的人都严肃地使用你的项目，那么使用一个严肃的版本。幸运的是，为那个版本决定是否使用 CalVer 比以往任何时候都要容易。
- 你的项目是否具有较大或不断变化的范围？
- 你的项目是否对时间敏感？是否有其他的外部变化驱动项目新版本的发布？
如果你对这些问题中的任何一个回答是肯定的，CalVer 的语义就会使 它成为你项目的有力选择。