1. 时序版本控制 2019.05.19
1.1. 总结
给定版本号 YEAR.MONTH.DAY.CHANGESET_IDENTIFIER ，递增版本:
- YEAR，年份版本，当年份变化时，
- MONTH，月版本，当月变化时，
- DAY，日版，当日变时，
- CHANGESET_IDENTIFIER，每次你向你的包/项目提交更改时。
1.2. 介绍
在软件管理的领域里存在着被称作“依赖地狱”的死亡之谷，系统规模越大，加入的包越多，你就越有可能在未来的某一天发现自己已深陷绝望之中。
在依赖高的系统中发布新版本包可能很快会成为噩梦。如果依赖关系过高，可能面临版本控制被锁死的风险（必须对每一个依赖包改版才能完成某次升级）。而如果依赖关系过于松散，又将无法避免版本的混乱（假设兼容于未来的多个版本已超出了合理数量）。当你项目的进展因为版本依赖被锁死或版本混乱变得不够简便和可靠，就意味着你正处于依赖地狱之中。
作为这个问题的解决方案，我提出了一组简单的规则和需求，这些规则和需求规定了如何分配和增加版本号。很简单，这些规则是基于时间的。您通过版本号的特定增量向项目传达更改。考虑 A.B.C.D (Year.Month.Day.Change)的版本格式。如果没有新的变化，就没有必要包括 D。例如:
有一天，您开始处理一个新项目，版本号是 2006.04.01。当天晚些时候，您向项目提交一个新更改。版本号是 2006.04.01.1。第二天，您的第一次提交将得到版本 2006.04.02。
我把这个系统称为“时序版本控制”。在这种模式下，版本号及其更改方式不仅更容易理解，而且比其他版本控制模式更容易“坚持”。没有更多的任意版本更新和回归，以纠正版本控制错误。
1.3. 时序版本控制规范(ChronVer)
本文件中的关键词“MAY”、“MUST”、“MUST NOT”、“OPTIONAL”、“RECOMMENDED”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”和“SHOULD NOT”应按照 RFC 2119 中的描述进行解释。
版本号必须采用
A.B.C.D形式，其中A、B、C和D是非负整数。A和D不能包含前导零。当B和C是个位数时，必须包含前导零。A为年版，B为月版，C为日版，D为变更集版。每个元素必须按数值递增。例如:2006.04.01 > 2006.04.02 > 2006.04.03。在前面提到的
A.B.C.D形式的版本号示例中，如果D为零，则D为可选包含。例如:2006.04.01等于2006.04.01.0。如果引入了向后不兼容的更改，则必须附加一个连字符和保留标签“break”。例如:
2006.04.03.12>2006.04.03.12-break。一旦一个版本包被发布，这个版本的内容绝对不能被修改。任何修改必须作为新版本发布。
1.4. 为什么使用时序版本?
对于其他版本方案，遵守是不一致的，充其量是松散的。合规吗? 请以语义版本控制为例，当应用程序一年发布几次或更少时，它是有意义的。我们现在正处在一个持续交付/集成的时代，v3.5.27 的概念在 web 应用程序或任何能够快速开发和发布的应用程序中已经消失了。您的用户几乎肯定对添加到版本号中的内容不感兴趣，也无法理解。有些人可以破译 10.14.5 (18F127a)，但读 2019.04.29.5 要愉快得多。
虽然工程师喜欢结构和顺序，但他们也受益于易用性。使用时序版本控制，它几乎不需要考虑去遵守。虽然其他版本控制方案几乎肯定仍有其用途，但时代变了，它们的用处也变了。
使用 Chronologic Versioning 的一个令人愉快的副作用是，可以快速查看项目中的哪些依赖项在一段时间内没有更新(如果这些依赖项使用了 Chronologic Versioning)。
时序版本控制为您提供了一种合理的方式来考虑依赖项管理，节省了您的时间和麻烦。
如果所有这些听起来都是可取的，那么开始使用 Chronologic Versioning 所需要做的就是声明您正在这样做，然后遵循规则。从你的自述链接到这个网站，让其他人知道规则，并可以从中受益。
1.5. 常见问题解答
这不是鼓励了快速开发和快速迭代吗?
绝对的! ChronVer 是关于快速开发的。
这听起来很适合个人项目，但我如何将其用于工作呢?
对许多团队来说，标记特性发布是一种常见的工作流程。下面是一个例子，说明了 ChronVer 如何在多贡献者环境中工作。
想象一下，你有一个团队正在开发一个特性，他们把任务分成了UI和实现两个分支。
2019.05.08.14 (base release)
├─ 2019.05.08.14-super-ui-enhance (UI fork)
│ └─ 2019.05.08.14-super-ui-enhance.13 (UI fork, later in the day)
└─ 2019.05.08.14-super-ui-please-work (implementation fork)
└─ 2019.05.08.14-super-ui-please-work.57 (implementation fork, later in the day)正如你所看到的，super-ui-enhance 和 super-ui-please-work 是在 2019.05.08 创建的一个版本的第十四次更新中派生出来的特性版本。
第二天的某个时候，这些分支可能是这样的:
2019.05.09-super-ui-enhance2019.05.09-super-ui-please-work.9
当您的工作合并到主分支时，您可以安全地省略来自版本号的 -FEATURE_NAME-CHANGESET_IDENTIFIER。
我应该如何处理功能的弃用?
弃用现有的功能是软件开发的一个正常部分，并且经常需要向前发展。当你弃用部分公共API(如果它存在)时，你应该做两件事:(1)更新你的文档，让用户知道更改(2)发布一个带有弃用的破坏版本。
“v1.2.3”是按时间顺序排列的版本吗?
不，“v1.2.3”不是一个按时间顺序排列的版本。但是，在按时间顺序排列的版本前加上“v”是表示版本号的常用方法(在英语中)。将“版本”缩写为“v”经常出现在版本控制中。例如: git tag v2006.04.03.13 -m "Release version 2006.04.03.13"，其中"v2006.04.03.13"为标签名称，按时间顺序显示的版本号为"2006.04.03.13"。
1.6. 关于
Chronologic Versioning 规范是由优秀体验的数字架构师 Paul Anthony Webb 编写的。
这个规格很大程度上借鉴了 SemVer，如果你想订购，你应该使用它，而不是ChronVer。如果您想留下反馈，请随时给我发邮件!
1.7. 许可证
知识共享- CC BY 3.0
1.8. 模块
要开始在你的项目中使用 ChronVer，你有这些有用的模块来帮助你。如果你想投稿，请给我发邮件!
node.js
Rust