如果您有一個項目，它釋放一個庫和一個應用程序，那麼您如何處理這兩者之間的版本號。庫與應用程序版本
示例：您的項目提供了一個庫，可將不同的文件格式轉換爲彼此。該圖書館已發佈，可供其他應用程序使用。但是你也可以釋放一個命令行應用程序，它使用這個庫並實現一個功能接口。
庫的新版本會導致應用程序的新版本（以利用所有新功能），但新版本的應用程序可能不會觸發庫的新版本。現在，版本號是如何處理的：完全獨立的，或者庫和應用程序版本是否依賴某種方式？
我會說使用單獨的版本號，當然文檔每個版本的應用程序需要什麼最低庫版本。如果它們總是具有相同的版本號，並且您只對同等編號的庫版本進行測試，那麼它們並不是真正獨立的組件，所以不要說它們是。將整批貨全部發放。
如果您將它們分開，那麼仍然可以在合適的時候爲它們提供相同的版本號 - 例如，在主要兼容性中斷之後，您可能同時發佈兩者的版本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
完全獨立的版本號，但命令行（或任何其他相關的）應用程序應該說明它在幫助部分或橫幅中編譯的庫的哪個版本。
通過這種方式，您將能夠判斷應用程序具有哪些功能並減少潛在的混淆，尤其是考慮到有人可能因任何原因而針對舊庫編譯較新的應用程序版本。此外，您可以將它們分開，並可以在不依賴於新應用程序版本的發佈等情況下添加庫中的功能。
如果你確定你會一直希望所有的應用程序和庫以鎖步方式走，那麼你可以使用相同的數字，但這不是一個強有力的理由增加了一個約束。
我們構建了一個使用框架的應用程序。我們爲兩者保留獨立的版本號。
這個效果很好，特別是現在框架和應用程序已經變得足夠大，可以由不同的團隊開發。
所以我認爲...保持版本號分開。