如果您有一个项目，它释放一个库和一个应用程序，那么您如何处理这两者之间的版本号。库与应用程序版本
示例：您的项目提供了一个库，可将不同的文件格式转换为彼此。该图书馆已发布，可供其他应用程序使用。但是你也可以释放一个命令行应用程序，它使用这个库并实现一个功能接口。
库的新版本会导致应用程序的新版本（以利用所有新功能），但新版本的应用程序可能不会触发库的新版本。现在，版本号是如何处理的：完全独立的，或者库和应用程序版本是否依赖某种方式？
我会说使用单独的版本号，当然文档每个版本的应用程序需要什么最低库版本。如果它们总是具有相同的版本号，并且您只对同等编号的库版本进行测试，那么它们并不是真正独立的组件，所以不要说它们是。将整批货全部发放。
如果您将它们分开，那么仍然可以在合适的时候为它们提供相同的版本号 - 例如，在主要兼容性中断之后，您可能同时发布两者的版本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
完全独立的版本号，但命令行（或任何其他相关的）应用程序应该说明它在帮助部分或横幅中编译的库的哪个版本。
通过这种方式，您将能够判断应用程序具有哪些功能并减少潜在的混淆，尤其是考虑到有人可能因任何原因而针对旧库编译较新的应用程序版本。此外，您可以将它们分开，并可以在不依赖于新应用程序版本的发布等情况下添加库中的功能。
如果你确定你会一直希望所有的应用程序和库以锁步方式走，那么你可以使用相同的数字，但这不是一个强有力的理由增加了一个约束。
我们构建了一个使用框架的应用程序。我们为两者保留独立的版本号。
这个效果很好，特别是现在框架和应用程序已经变得足够大，可以由不同的团队开发。
所以我认为...保持版本号分开。