Rap*_*orX 33 version-control project-management
我知道没有关于软件版本控制的固定规则,但我有几个问题.
1)如何正确升级版本
我有一个小软件,我刚刚开始,因为我从头开始,我开始使用0.1版本.
随着我添加了更多功能,我一直在升级次要号码.现在我在v0.5.7(次要(.5)用于新功能和修订版(.7)进行错误修复和微小更改),事情是该程序几乎完成分发,但现在我"失踪" "几个小版本,你们如何处理这种情况？你只是跳过数字吗？
这让我想到了第二个问题.
2)哪个是好的起始版本号
我即将开始一个新项目.这个时间并不是一个小项目,并且将公开并且可以免费修改,我不希望遇到上述问题.那么这将是一个很好的起点？
奖金问题:
3)数字大于10可以吗？像v1.25或v2.2.30？
我没有看到带有这种编号的软件(可能只在帮助部分或他们的网页中显示它),再次我知道没有规则,但似乎有一般同意如何保留版本号.
Von*_*onC 36
版本控制策略有时可能有点疯狂(请参阅版本号和JSR277,或 Oracle,其Oracle Database 11g第2版: 11.2.0.1.0.
另请参阅软件版本控制是荒谬的).
但您可以从查看Eclipse Version Number策略开始.
如果您确实认为您需要超过三位数,则此VRMF维护流交付工具术语解释也很有意思,但对于1.0版软件更有用,其中修订包和临时修订都是有序的.
1 /"已经发货": 1.0.0
也称为" 1.oh-oh"版本.至少,它就在那里,您可以开始获得反馈并快速迭代.
2/0.x如果仍然缺少主要功能; 1.0.0如果主要功能在那里.
3 /是的,但我想说的只是寿命超过几年的大型项目(通常是十年)
请注意,"正确"(虽然在语义版本2.0.0中的长度描述)也可以由更实用的因素指导:
发布候选版Git v1.9-rc2现在可以在通常的地方进行测试.
我听说有传言说各种第三方工具都不喜欢两位数的版本号(例如"Git 2.0"),并且在用户安装v1.9-rc1时左右开始向左右移动.
虽然很容易因为他们草率的假设而嘲笑他们,但我也很实际,并且不介意调用即将发布的版本v1.9.0来帮助他们.如果我们走那条路(此时我倾向于走这条路),版本控制方案将是:
- 下一个候选版本将是
v1.9.0-rc3,而不是v1.9-rc3;- 第一个维护版本
v1.9.0将是v1.9.1(和第N个v1.9.N); 和- v1.9.0之后的功能版本将是v1.10.0或v2.0.0,具体取决于我们正在查看的功能跳转的大小.
2019年2月更新:semver本身即将发展(再次,在semver2之后).
请参阅" SemVer的下一步是什么 ",以及semver/semver/CONTRIBUTING.
在我们公司，我们使用四个令牌版本控制概念。它类似于abcd类型：
(major).(feature).(revision).(bug/refactoring)
它与我们在开发生命周期中使用的问题类型有关。我们可以一目了然地跟踪以下两个版本之间所做的或更改的内容。通过比较以下两个版本号，您可以确定已完成问题的数量和类型。如需更多信息，请点击此处查看完整文档。