基于项目发布日期的版本控制约定

摘要

项目版本号的组成 YEAR.MONTH.DAY.CHANGESET_IDENTIFIER，解释如下：

YEAR 年份更改时，
MONTH 当月份更改时，
DAY 当日期更改时，
CHANGESET_IDENTIFIER 每次对包/项目进行更改时。

介绍

在软件管理领域中，存在一个可怕的地方，称为“依赖地狱”。系统规模越大，集成到软件中的软件包越多，有一天，你越有可能在这种绝望之中找到自己。

在具有许多依赖性的系统中，发布新的软件包版本可能很快成为噩梦。如果依赖性说明太严格，则存在版本锁定的危险（无法升级软件包而不必释放每个依赖性软件包的新版本）。如果对依赖关系的定义过于宽松，你将不可避免地被版本混杂（假设与更多合理版本的将来版本兼容）所困扰。当版本锁定和/或版本混杂使你无法轻松，安全地将项目向前移动时，依赖地狱就在你身边。

作为此问题的解决方案，我提出了一组简单的规则和要求，这些规则和要求规定了如何分配和递增版本号。很简单，这些规则是基于时间的。你可以使用版本号的特定增量传达对项目的更改。考虑A.B.C.D（Year.Month.Day.Change）的版本格式。D如果没有新的更改，则不必包括在内。例如：

你有一天会开始一个新项目的工作，版本号为2006.04.01。当天晚些时候，你对项目进行了新更改。版本号为2006.04.01.1。第二天，你的第一次提交将产生版本2006.04.02。

我称此系统为“时间版本控制”。在此方案下，版本号及其更改方式不仅比其他版本控制方案更容易理解，而且更有可能“黏住”。不再需要任意版本更新和回归来更正版本错误。

时间版本控制规范（ChronVer）

本文档中的关键词“ MAY”，“ MUST”，“ MUST NOT”，“ OPTIONAL”，“推荐”，“ 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如果为零，则为可选包含。例如：2006.04.01等于2006.04.01.0。
如果引入了向后不兼容的更改，则必须添加连字符和保留的标签“ break”。例如：2006.04.03.12> 2006.04.03.12-break。
一旦发布了版本化的软件包，就不得修改该版本的内容。任何修改都必须作为新版本发布。

为什么要使用时间版本控制？

使用其他版本控制方案时，依从性最高且不一致。合规？请。以语义版本控制为例，当一年或几次发布应用程序时有意义。我们现在处在持续交付/集成的时代，a的概念v3.5.27在网络应用程序或快速发展和发布的任何内容中都消失了。你的用户几乎肯定不会对你的版本号感兴趣，也不会理解你的版本号。有些人可以破译，10.14.5 (18F127a)但是阅读起来要愉快得多2019.04.29.5。

尽管工程师喜欢结构和顺序，但他们也从易用性中受益。使用Chronologic Versioning，几乎不需要考虑就可以遵循。尽管几乎可以肯定其他版本控制方案仍然可以使用，但是时代已经改变，其实用性也有所改变。

使用Chronologic Versioning的一个令人愉快的副作用是能够一目了然地查看项目中的哪些依赖项在一段时间内没有更新（如果这些依赖项正在使用Chronologic Versioning）。

时序版本控制为你提供了一种思考依赖管理的理智方式，从而节省了时间和麻烦。

如果所有这些听起来都合乎需要，那么开始使用Chronologic Versioning所需要做的就是声明你正在这样做，然后遵守规则。从你的自述文件链接到本网站，以便其他人知道这些规则并从中受益。

常问问题

这不是在鼓励快速发展和快速迭代吗？ 绝对！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是从上创建的发行版的第14个更新派生的功能发行版2019.05.08。

第二天的某个时候，这些分支可能看起来像这样：

2019.05.09-super-ui-enhance
2019.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”。

关于

时序版本管理规范由经验丰富的数字架构师Paul Anthony Webb撰写。

该规范是从SemVer大量借鉴而来的，如果你想订购而不是ChronVer，则应该使用它。如果你想留下反馈，请随时给我发送电子邮件！

License

Creative Commons — CC BY 3.0 https://creativecommons.org/licenses/by/3.0

Modules

要开始在你的项目中使用ChronVer，你需要这些有用的模块来为你提供帮助。如果你想贡献自己的力量，请给我发电子邮件！

Node.js

Rust

https://crates.io/crates/chronver

Example: https://calver.org

原文地址：https://chronver.org

最后修改于 2020-02-22