当项目的各个部分之间的兼容性不同时如何使用语义版本控制

如何解决当项目的各个部分之间的兼容性不同时如何使用语义版本控制

假设一个由多个部分组成的项目

1. 文件格式定义
2. 与文件格式交互的库
3. 一个使用库来执行任务的 CLI 实用程序

我可以在不破坏 (1) 或 (2) 的情况下对 (3) 进行非向后兼容更改。

我可以在不破坏 (1) 的情况下对 (2) 进行非向后兼容更改，但 (3) 会破坏。

我可以在不破坏 (3) 的情况下对 (1) 进行非向后兼容更改，但 (2) 会破坏。

这是否意味着这些部分必须是不同的项目，所以它们可以有不同的版本号？

解决方法

版本字符串可以指一组独立版本化的 API/包、单个 API、API 和实现等。您的客户期望。语义版本控制就是告诉您的客户，如果他们接受您的更新，您认为他们会承担哪些风险。

根据您的描述，我认为您需要进行版本控制的三件事：

1. 文件格式。
2. 图书馆。
3. CLI 实用程序应用程序。

是否在一个、两个或三个存储库中开发它们取决于您。独立于依赖于它的任何实现来开发和版本化文件格式规范并不少见。您的库和 CLI 实用程序是属于一起还是属于不同的存储库，这取决于您的开发流程物流和客户期望。您是否有不需要您的实用程序的图书馆使用者？

无论它们位于一个、两个或三个存储库中，您都应该单独打包和版本化它们。这意味着独立的提要和打包脚本。