如果我们有一个项目，该项目发布了一个库和一个应用程序，那么我们将如何处理两者之间的版本号。

示例：项目提供了一个库，该库可以将不同的文件格式相互转换。该库已发布，可以包含在其他应用程序中。但是，我们还发布了一个命令行应用程序，该应用程序使用此库并实现该功能的接口。

库的新发行版导致应用程序的新发行版(以利用所有新功能)，但是应用程序的新发行版可能不会触发库的新发行版。现在如何处理版本号：完全独立，还是应该以某种方式依赖库和应用程序版本？

解决方案

完全独立的版本号，但命令行(或者任何其他从属)应用程序应在帮助部分或者横幅中说明针对哪个库版本进行编译。

这样，我们将能够分辨出应用程序将具有哪些功能并减少潜在的混乱，尤其是考虑到有人可以出于任何原因针对旧库编译较新的应用程序版本。此外，我们可以将它们解耦，并且可以在库中添加功能，而无需依赖于新应用程序版本的发布等。

如果我们确定始终希望所有应用程序和库都同步运行，则可以使用相同的数字，但这并不是出于很强的理由而添加了约束。

我们构建了一个使用框架的应用程序。我们为两者保留单独的版本号。

这很好，尤其是现在框架和应用程序已经足够大，可以由不同的团队开发。

因此，我的看法是...将版本号分开。

我想说的是使用单独的版本号，当然还要记录每个版本的应用程序要求的最低库版本。如果它们始终具有相同的版本号，并且我们只对同号的库版本进行了应用测试，那么它们并不是真正独立的组件，因此不要说它们是独立的。一次全部释放。

如果将它们分开，则仍可以在适当的时候给它们提供相同的版本号，例如，在重大兼容性中断之后，我们可能会同时发布两者的2.0版。

以下示例说明：xsltproc(命令行应用程序)作为libxslt(库)的一部分发布，因此没有自己的版本号。但是libxslt依赖于其他两个库，并且这些库的版本号是独立的。

$ xsltproc --version
Using libxml 20628, libxslt 10120 and libexslt 813
xsltproc was compiled against libxml 20628, libxslt 10120 and libexslt 813
libxslt 10120 was compiled against libxml 20628
libexslt 813 was compiled against libxml 20628