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

问题描述

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

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

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

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

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

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

解决方法

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

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

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

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

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