当前，我使用API的语义版本控制。
版本的演变过程如下：
当您更改不兼容的API时的主要版本
MINOR版本，当您以向后兼容的方式添加功能时
[PATCH版本，当您进行向后兼容的错误修复
如果仅更新文档（草签，内部文档，YAML等）以添加示例，或更正对API的描述，我应该增加PATCH吗？
感谢您的帮助;）
如果仅更新文档（草签，内部文档，YAML等）以添加示例，或更正对API的描述，我应该增加PATCH吗？
取决于示例/更正。它是否代表了对API使用的先前理解的突破？这是一个非常人为的讨论示例：
API：int plus(int a, int b)
文档：int plus(int a, int b) sums a + b.
以上发布为1.0.0，然后有人检查了代码并指出在溢出时，该函数返回0。
更新的文档：int plus(int a, int b) sums a + b where a < 32767 and b < 32767, otherwise, returns 0.
因此，这是否是一项重大更改，取决于a + b溢出时的语言及其行为。有些语言会引发异常或段错误，而其他语言则通常会简单地返回某种模数结果。假设它是C，在这种情况下，此文档更改可能是一个重大更改（嗯，实际上可能是大多数编程语言）。
这里的意思是，初始文档通常不比对API本身进行表面重述要好得多。当客户对结果感到惊讶时，随后来自客户的投诉（错误报告）通常会推动下一轮文档更改。因此，是的，即使开发人员的初衷没有改变，但文档的确代表了预期结果的重大变化。
是否已对文档进行更改以使其完全符合客户在使用中所期望/见证的内容，那么不，这不是一个重大更改。
该文档是功能集的一部分。回填缺少的文档通常是一项附加功能，因此您会遇到次要版本。较小的更正将是一个补丁。