如何在版本中維護版本/構建組件？

Question

閱讀的文章很多/質量檢查/常見問題/書籍後，我變得想 是[MAJOR] [MINOR]。[REV]是最有用的版本架構 描述項目版本（版本架構 對之間的兼容性開發人員，不用於營銷）。

主要變化是向後兼容以及需要變更的文件，GUID的，等 項目名稱，路徑

細微的變化是向後兼容。馬克介紹新的 功能。

修復安全/錯誤的REV。向後和向前兼容。

在我的工作中，很多項目都依賴於在發佈服務器（FTP）上存儲 的內部庫。他們有不同的版本，如：

 
    1.0.0 
    1.1.0 
    1.1.1 

路徑依賴庫包括用於自動下載構建腳本編碼爲的lib目錄版本組件和硬 。

問題：通常的做法是將內容路徑包含到 內部開發的構建腳本中？

問題：最好：包含庫名中的版本號或 不是？包含哪些組件？例如：

 
    libfoo-1.so 
    libfoo-1.2.jar 
    libfoo-2.3.14.dll 

如果你只包括[MAJOR]您可以在源 內聯libary名稱和版本的變化，你不需要修改任何代碼。由於 庫具有固定名稱，因此您始終可以通過調用相應的函數在 運行庫中詢問庫版本。

如果包括[MAJOR] [MINOR]組件每個細微的變化 需要更新所有受影響的項目（招標調用LoadLibrary， CLASSPATH的環境變量）。並且您無法在運行時檢查版本 在運行時搜索庫的標準機制通常是 不允許按名稱加載通配符（如「libbar-2。*」）。

我認爲包括[REV]是不需要的。您只需要 以某種方式爲錯誤報告提供此組件。

問：我打算實現這樣的模式：包發佈到 路徑，如：

 
    /srv/projs/foo/1.2.2 

，並從以前的路徑創建符號鏈接

 
    /srv/projs/foo/1.2 

。所以每個相關項目都不需要使用 任何步驟來獲取最新的庫。任何人使用這種模式？

Answer 1

如果您仍然不使用（任何）SCM，那麼您就走錯了路。 如果不使用生成器，它可以與用於SCM集成 - 你是在錯誤的道路上再次

文件的固定名稱（不*任何版本號），則它是維持最簡單的方法來源（你必須修改內部沒有內部）