语义版本控制规范(SemVer)定义:
主要版本零(0.y.z)用于初始开发。任何事情都可能随时改变。公共API不应被视为稳定。
因此从1.0.0
开始被认为是稳定的。
在启动项目时,通常使用版本0.1.0
并逐渐增加,项目可能会有0.20.3
这样的数月/年,并且它是“稳定的”。
因此,想知道在将项目提交到服务器1.0.0
之前,除了标准,参数之外还应该考虑哪些好的做法。
你是如何处理这个的?
如果在3个月内没有问题/代码活动,则转储版本?
答案 0 :(得分:0)
开发团队决定何时拥有1.0.0版本。项目可能会在很长一段时间内保持实验/原型模式。这里唯一重要的是接口和实现是否可以被认为是完整的。你的目标是什么?您是否已准备好所有计划的v1功能?你有疑问吗?实现是否符合文档化界面?
有些团队没有映射到完整semver spec的工作流,但是他们使用需要semver版本字符串的打包/发布工具。为了合法,他们永远不会发布版本1.0.0,所以任何版本颠簸字面上都没有完整的SemVer语义。请参阅#4 in the spec。
当我看到SomeLib.0.20.3.pkg时,我认为它不稳定。无论是否曾经发生任何此类变化,都可能会在下一次轻微的场地碰撞中发生突破性变化。 SemVer是一个允许SomeLib开发人员在这种特殊情况下破坏事情而不另行通知的合同。
规范中没有任何内容阻止团队发布1.0.0然后返回到0.x.x版本的长序列,如果他们希望以这种方式运行的话。这与使用预发布标记类似,但不完全相同。当您发布1.0.1-prerelease时,您至少暗示有意发布从1.0.0派生的工作,这是一个错误修复,但预发布标记是警告标签,您还不确定更改的安全性制作。从1.0.0开始到0.x.x版本的序列说你甚至可能不再从1.0.0派生。基本上,所有的赌注都会重新开始。
如果您需要对此事进一步澄清,请询问,我很乐意尝试回答有关SemVer的任何问题。