同步版本編號

Question

這個問題混合了一些項目管理和開發。我瞭解[主要]。[小]。[補丁]計劃版本編號的項目。通過我的客戶項目，我將這些編號主要用於內部目的，因此團隊可以說「v1.3.2的進展是什麼？」，而不是通過涉及的功能來引用項目。

但是，有時我們的客戶一次有多個次要版本。每個次要版本都包含一組獨立的功能（與客戶公司的不同部門合作），但兩者都可以啓動不同的時間。因此，如果我們將它們標記爲v1.3.3和v1.3.4，則v1.3.4版本可能早於v1.3.3發佈，然後整個命名方案將無效。

如果您不知道哪些版本會首先發布（由於等待客戶批准或其他外部調度衝突），您如何在內部引用這些不同版本？

謝謝！

Answer 1

很簡單 - 我們不會在我們發佈之前分配版本號。問題解決了！

這聽起來可能很輕浮，但這是事實。當然，我們會有內部項目，例如配音「v5.5」，但是那些與目前在v5.4.x的下一次迭代中的工作是分離的和獨立的，只有在完成和發佈後纔會接收下一個「x」值。當v5.5準備就緒時，5.4的工作就停止了，我們將對5.4所做的任何更改合併到5.5中，然後我們釋放5.5.0。

如果您針對不同的客戶端（您的案例中的部門）有單獨的版本，則可以採用修改的版本控制方案。我們所做的是使用[major]。[minor]。[client]。[patch]，例如5.4.client1.4。 [patch]將是獨立的，只對那個特定的客戶端有意義，而[major]。[minor]將對應於我們分離的主代碼庫的[major]。[minor]版本。例如，我們可能同時在5.5，5.4.x和5.4.client1.x上工作。當5.5準備就緒時，5.4.x會合併到那個中，然後這兩個項目都會摺疊到5.5.x中，但客戶端項目可能沒有準備好合並所有這些更改，因此它將保持5.4.client1.x，直到它被提出到5.5，然後變成5.5.client1.x。

這可能聽起來令人困惑，但它確實對我們非常有效。我們之前採用了這種方案的一種變體，其中客戶名稱被附加到完整版本號，即[major]。[minor]。[patch] _ [client];然而，[major]。[minor]對應於從其分支/最後合併到的「核心」[major] [minor]，[patch]完全獨立於其他版本，並且僅對此有意義（這就是爲什麼我們稍後調換了[client]和[patch]的相對位置，爲了說明5.4.7實際上可能有更多的修正/比5.4.12.client1更「當前」，並且更好溝通這種獨立性

當一個客戶特定的項目合併回來，當然，你放棄它並增加到下一個[補丁]，或者跳轉到下一個[minor]甚至[major]版本，這取決於工作的性質，當一個客戶項目合併到5.4.x項目中，然後我們從該版本6.0發佈時，偶爾會導致一些暫時的混淆，然後記住將內部5.5項目重命名爲6.1，但是它工作nonethel ESS。

作爲您的環境的替代方案，只需通過客戶（部門）名稱（例如，會計項目，人力資源項目等。不要在內部使用版本號來處理這類事情，因爲正如你所看到的，它只會導致5.4.6之後但5.4.9之前出現的版本5.4.6的混淆;同時5.4.8從未被釋放，因爲它被取消了。這只是一團糟，所以遠離這一點。只需通過客戶名稱撥打您的項目，然後分配下一個號碼