卡塔尔vs葡萄牙分析Creative Commons (CC)试图利用弗(日历版本),但是遇到了太多的问题和决定SemVer(语义版本控制)。

为什么我们选择弗

年前,CC技术团队标准化的使用弗作为我们的版本控制方案。具体来说,我们选择YYYY.0M.MICRO。弗:

1. YYYY-年- 2006、2016、2106

2. 0米-在月01、02……11、12

3. 微——第三,通常最终数字版本。有时也称为“补丁”。

使用弗灵感来源于Ubuntu,皮普,SaltStack等等。它不仅被认为弗匹配SemVer在用户沟通潜在的风险,但是也给了额外的时间上下文。此外,许多人认为,SemVer的承诺MAJOR.MINOR.PATCH经常去实现他们失去意义和之间的差异小/补丁太定义糟糕的(稍后将详细介绍这些)。

工作中遇到的问题与弗

时间/持续时间不是主要相关

弗通常青睐的项目的时间/时间是主要的相关性(例Ubuntu发行版支持有限窗口)。然而,没有一个CC的项目时间/时间作为主要的相关性。

主要期望和缓慢的迭代

SemVer公约是长期的规范化。许多许多用户,尤其是开发人员,预计第一个数字版本控制方案来表示变化的严重性。与YYYY指示当前版本,YYYY.0M.MICRO版本控制方案可能会设定一个期望(如重大变化或改进。2021.09.1来2022.02.1)即使内容的变化是微不足道的。与YYYY显示原始版本,动作缓慢但稳定和功能可能出现放弃或不安全(前发布。2019.03.2在2022年)。

可怜的支持弗

我们还遇到了可怜的支持弗在软件和系统。例如,目前带前导零NPM,减免CDN集成(弗·CDN兼容性问题# 588·creative commons /词汇)。

使用SemVer

我们的实验与弗是科学方法的胜利。今天,我们可以更有信心SemVer将CC软件的开发者和用户比弗。

SemVer的承诺承诺

CC技术团队认为SemVer一系列承诺我们做CC开源软件的用户和开发者。我们也许不能实现完美履行这些承诺,但他们期望轮廓,我们希望你能开一个问题如果我们犯了一个错误。

CC SemVer细节

我们将使用SemVer(语义版本控制)。添加额外的清晰,我们将避免混合功能变化和bug修复版本:

1. 主要当你进行不兼容的API更改版本
2. 小版本当你向后兼容的方式添加功能
   • 释放,增加小版本不得包括bug修复
3. 补丁当你向后兼容的bug修复版本
   • 释放,增加补丁版本不得包括功能添加

当一个错误修复从技术上讲变化的功能,我们将发布一个bug修复(只递增补丁改变保存版本)目标功能。