3

我想调和 RDD 和 Breaking.Feature.Fix 版本控制。

这是我的主要问题，我将在 NPM 上发布我的 README，但我不知道如何在没有实际代码的情况下对软件进行版本控制。自述文件将经历许多更改，它必须以某种方式反映在版本中。

以下是我面临的问题：

  • 自述文件中记录的 API 的重大更改是否会被视为重大更改？请记住，此时没有代码。
  • 第一次 README 提交的版本应该是什么？什么是约定？
  • 我应该在第一次代码提交时碰到哪个部分（主要、次要或补丁）？同样，在那之前我只有一个自述文件。
  • 在第一次提交代码之前，我应该为我的 README 版本使用预发布标签吗？
4

2 回答 2

1

这是我的做法（已编辑）：

我不会将文档（包括 RDD）与实现代码分开。我总是从 1.0.0 开始我的软件，并且通常从 RDD 文档开始，该文档可能有也可能没有附带代码，具体取决于实现的复杂性。

在有代码之前，我根本不会开始修改版本号。如果您的 RDD 是规范并且有其他人从您的文档中实现，则此方法可能不起作用。在这种情况下，您可以考虑将文档放在自己的存储库中并维护自己的版本历史，这与实现软件的版本历史是分开的。如果你分别维护它们，你的 RDD 版本规则应该遵循与软件版本规则相同的原则。破坏.功能.修复。

否则，如果您不打算为您的 RDD 维护单独的版本控制，那么在任何代码存在之前，我认为从 1.0.0 开始通常是可以的，并且在您开始推送实现代码之前根本不要增加它。我会将任何未实现的文档放在一个docs/RDD文件夹或类似文件夹中，以将其与已实现代码的文档区分开来。

我的原始答案适用于 CODE 版本，而不是文档版本：

  • “自述文件中记录的 API 中的重大更改是否会被视为重大更改？” - 是的，一点没错。
  • “我的第一个版本应该是什么？” -- 从 1.0.0 开始。版本号是针对软件的，而不是针对人的。每个重大更改都应与主要版本号的更改进行沟通。
  • “我应该在第一次代码提交时碰到哪一部分？” -- 你的第一个代码提交应该是@1.0.0。
  • “我应该使用预发布标签吗？” - 您应该将推荐的稳定版本标记为最新。如果您有一个需要更广泛测试但尚未准备好用于一般生产用途的实验性候选版本，请使用预发布标签。

您可以在“软件版本已损坏”中阅读有关我的软件版本建议的更多信息。

于 2016-01-22T03:23:46.973 回答
0

由于您不必使用“真正的”RDD，并且由于 RDD 的主要前提之一是对于认为 DDD 太重的人来说它是 DDD，所以我想说从 RDD 中获取您喜欢的内容（我喜欢想法）并使用它，如果您“正确地做 RDD”，请不要担心。

至于你的具体问题：

是的，我会说一个不向后兼容的 API 更改绝对是一个主要版本的颠簸（至少在你到达 V1 之后）。

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

取决于变化的多少。

我不——如果你发现价值，我会的。

于 2016-01-19T02:39:35.577 回答