问如何使我的版本适应自述驱动的开发？

EN

我是这样做的(编辑)：

我不将文档(包括RDD)与实现代码分开。我总是在1.0.0开始我的软件，并且通常从一个RDD文档开始，这个文档可能有也可能没有伴随的代码，这取决于实现的复杂性。

在有代码之前，我根本不会开始碰撞版本号。如果您的RDD是一种规范，并且有其他人从您的文档中实现，则此方法可能无法工作。在这种情况下，您可以考虑将文档放在自己的存储库中，并维护自己的版本历史记录，这与实现软件的版本历史是分开的。如果单独维护RDD版本规则，则RDD版本规则应遵循与软件版本规则相同的原则。Breaking.Feature.Fix。

否则，如果您不打算在任何代码存在之前为您的RDD维护单独的版本控制，我认为通常最好从1.0.0开始，在开始推进实现代码之前根本不增加它。我会将任何未实现的文档放在docs/RDD文件夹中或类似的文件夹中，以区别于已经实现的代码的文档。

我最初的答案适用于代码版本，而不是文档版本：

• “API中的一个重大变化--记录在自述中--会被认为是一个重大的变化吗？”--是的，绝对是这样。
• “我的第一个版本应该是什么？”-从1.0.0开始。版本号是给软件的，而不是人的。每一次重大更改都应通过对主版本号的更改来传达。
• “在第一次提交代码时，我应该选择哪个部分？”--您的第一个代码提交应该是@1.0.0。
• “我应该使用预发布标记吗？”--您应该将推荐的稳定版本标记为最新的。如果您有一个需要更广泛测试但尚未准备好用于一般生产的实验性发布候选版本，请使用预发布标记。

您可以在“软件版本坏了”中阅读更多关于我的软件版本建议的内容。

因为你没有被迫使用‘真正’的RDD，而且由于RDD的主要前提之一是DDD对于那些认为DDD太重的人来说是DDD，所以我想说，从RDD中拿出你喜欢的东西(我喜欢这个想法)并使用它，如果你是“做RDD的正确的”，不要担心。

关于你的具体问题：

是的，我会说，非向后兼容的API更改肯定是一个主要的版本改进(至少在您到达V1之后)。

我很谦虚，我倾向于从0.0.0开始。--如果你认为你的第一个努力是一般的发布质量，那么就用1.0.0吧！

取决于变化的数量。

我不--如果你找到了价值，我会的。