目前，我們使用以下的版本編號方案，爲我們的C＃的WinForms項目：。如何在敏捷項目中進行版本編號？
「主要版本」，「次要版本」，「迭代次數」
「是迭代中構建號碼」我們希望能夠通過查看版本號來確定迭代中的迭代次數和內部版本號。
過去，我們做了類似「主要版本」，「次要版本」，「從1.0開始的順序版本號」。例如，「4.0.648」意味着自1.0版以來有648次構建 - 但這些信息相當無用且軼事化，這就是爲什麼我們改變以反映迭代並在迭代中構建的原因。
因此，考慮到這個新的敏捷版本編號，我們現在有一個問題，即不同的產品組想要對其項目的迭代進行更改。在這種情況下，版本號是沒有意義的，因爲它們的迭代和內部版本號不一致。例如，我的項目的最後一個版本是1.0.5.1，指示了第5版的第一個版本。現在這個第三次迭代中的另一個項目想對我的項目進行更改並重建。
我應該如何應對這種情況？你如何在你的敏捷項目中進行版本編號？
我跟蹤敏捷項目的迭代，而不是軟件項目的迭代。如果後期啓動器端項目在另一個項目之後加入，它將因此啓動當前的敏捷項目迭代，並且不會發生錯位。
敏捷項目領域之外的技術項目不應該可能與域內的項目進行交互。這將是該流程的PM失敗，並且在共享代碼庫與分支一起使用的所有情況下都應該被淘汰，並在項目完成後作爲清理步驟打入幹線。
我喜歡Major.Minor.Build.Revision其中Build - 大衆發佈的數量，Revision - 從源代碼版本的系統修訂
我喜歡把構建和發佈過程中從隊伍發展過程中分離出來，所以我很難添加的迭代，衝刺或類似的版本。你的情況是一個很好的例子，說明如何混合這兩樣東西不容易管理。如果你在項目中間改變方法（不管原因可能是什麼），該怎麼辦？
回答你的問題，我們已經使用了兩年的Scrum，而我們的版本格式是經典的Major.Minor.Upgrade.Build（我們只在錯誤修正中使用升級）。最後，使用Build版本並不是強制性的，因爲您只需要它從相同版本中消除不同軟件包的歧義，但是您可以使用另一個代表某種私有版本的符號。
就我個人而言，我認爲我最喜歡的發佈版本是完全廢除整個major.minor的東西。我認爲這對於內部應用程序來說確實可行，但爲此，它使生活變得更加輕鬆。
通常，如果您正在開發面向內部的應用程序，我注意到業務從未真正關心他們使用的主要/次要版本。相反，他們傾向於想知道a）下一個版本何時發佈以及b）將要發佈或發佈的內容 - 這就是關於它的內容。試圖保持這樣一個事實，即當你沒有關心時，你正在使用FOO-4.34.0.1-a和BAR-3.19.4.1，這隻會使通信複雜化。
在之前的組中，除了項目啓動之外，我們並沒有真正的主要發佈版本。每一次發佈都與上一版一樣「重大」。
因此，我認爲他們做了明智的事情，而是作爲PROJECT_RELEASENUM傳達給企業。每當我們發佈一個版本時，版本號增加'1'，補丁爲PROJECT_RELEASENUM_PATCHNUM，這也增加了'1'。
它與概念，發展爲持續短跑，直到企業擁有所有他們需要的功能做效果很好（這在實踐中從未發生過 - 總是有東西更多他們想要的）。企業所有者理解它，開發人員可以溝通它，它自然適應我們所擁有的持續發展模式。
敏捷開發人員沒有版本號。它記錄了文檔。 – cletus 2009-01-27 11:57:47
他們將如何追蹤版本號？ – simgineer 2011-12-15 06:51:23