2017-08-25 73 views
1

这不是一种编码,而是一个过程问题。发布后版本控制和SemVer 2.0(sematic verisoning)

我正在构建可能需要某些市场或一般情况下的发布后修补程序或功能添加的软件。

继追加-标签到指定的版本号,以纪念我想一个+标签添加到版本号,以纪念这种释放后的版本的SemVer 2.0(http://semver.org/spec/v2.0.0-rc.2.html)方案。

只要不发生重大更改,这将导致以下版本树:

1.0.1-rc1        // initial pre-release 
| 
1.0.1-rc2        // second pre-release 
| 
1.0.1         // actual release 
| 
|-------- 1.0.1+1 --- 1.0.1+2   // post release path 
| 
| 
| 
1.0.2         //non breaking 
| 
2.1.0         //1st breaking 

有没有更好的方式来做到这一点完全符合semver?

npm,jspm和yarn如何处理这种semVer延伸?

我错过了一件?有没有“官方”解决方案?

回答

1

继semver属,我建议似乎是“无效”

  • 生成的元数据可以通过附加一个加号和一系列点的被表示分隔的标识符紧接补丁或预发布版本。标识符必须只包含ASCII字母数字和连字符[0-9A-Za-z-]。确定版本优先级时,应该忽略构建元数据。 因此,具有相同版本但不同构建元数据的两个包被认为是相同版本。示例:1.0.0-alpha + 001,1.0.0 + 20130313144700,1.0.0-beta + exp.sha.5114f85。