语义版本控制规范 (SemVer) 定义：
主要版本零 (0.y.z) 用于初始开发。任何事情都可能随时改变。公共 API 不应该被认为是稳定的。
所以以1.0.0 开头被认为是稳定的。
正常启动项目时，使用版本0.1.0并逐渐增加，有一个点，项目可以有几个月/几年的0.20.3之类的东西，它是“稳定的”。
因此，想知道在将项目提交到服务器 1.0.0 之前，除了标准和参数之外，还应该遵循哪些良好做法。
你是如何处理这个问题的？
如果在 3 个月内没有问题/代码活动，版本是否被转储？
【问题讨论】：
开发团队决定何时拥有 1.0.0 版本。一个项目有可能在很长一段时间内保持在实验/原型模式。这里唯一重要的是接口和实现是否可以被认为是完整的。你的目标是什么？您是否具备所有计划的 v1 功能？你有疑问w.r.t吗？实现与文档化接口的一致性？
有些团队没有映射到完整 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 的作品，这是一个错误修复，但 prerelease 标签是警告标签，您还不确定您所做更改的安全性制成。从 1.0.0 到一系列 0.x.x 版本表明您甚至可能不再从 1.0.0 派生。基本上，所有的赌注都再次关闭。
如果您需要对此问题进行任何进一步的说明，请询问，我很乐意尝试回答有关 SemVer 的任何问题。
【讨论】：