语义版本控制规范（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的任何问题。