案例1：這階段公司內部在測試一個即將上線的產品，好幾次都遇到運行良好的服務在某個時間段後不能提供正確服務的情況，由於產品涉及到多個端，協作人員衆多，而且各端軟件的更替也較頻繁，在從內部排查問題的同時也在從外部着手確定是否有人更改過某個程序，衆研發人員都說沒有更改過程序。但是隨着排查的深入往往會發現是某個人搞混了自己發佈程序的版本。
案例2：團隊中有人在發佈動態庫或應用程序時採用日期來做版本號，在頻繁迭代的過程中無法使應用程序和源碼管理系統中版本對應起來，不利於定位問題。
案例3：使用源碼管理系統提交時爲了偷懶或者忽視，不標註或隨意填寫改動描述，在進行代碼回退時那個費勁。
版本管理的重要性在研發工作中不言而喻，缺乏規範化在研發階段會嚴重影響開發效率，在測試階段也會造成很多無意識的錯誤，一旦到了發佈階段造成的損失會更大。記得在一次公司規範管理的會議上，老總曾提到過我們的硬件產品由於燒錄程序版本的問題給公司造成了很大的經濟和聲譽損失。所以如何規範化版本管理首先作爲研發人員和管理人員的我們要在心裏重視起來，進而採取措施去規範化版本。
源代碼和文檔管理：如果你的公司還沒用源碼管理工具進行源碼管理，你出頭的機會就來了，向他們推薦SVN和GIT吧（別笑，還真有很多公司沒有形成企業級的規範，我就逮到這麼一個機會），現在據我瞭解大部分商業公司還是在使用SVN，剛纔案例3提到的提交改動描述的問題，SVN就沒有GIT做得好，SVN可以提交空註釋，於是就發現衆多偷懶的程序員們一片片空白的註釋，這純粹是挖坑埋自己......。提到文檔，我們程序員最最討厭了，可是又不得不寫，用一些富文本工具寫出的文檔無法進行內容比對，建議使用markdown來維護文檔。
二進制程序的管理：對於二進制程序的版本規則，案例1給我們的教訓是必須得有，案例2告訴我們版本規則必須要能夠表達一定的含義或者對應一致的源文件。最通用的形式通常是major.minor.build,在新版本推出時，應更新major、minor或是build的版號，決定於變更的大小。當有極大的更新時，會增加major的版號。而當有大更新，但不至於更新major時，會更新minor的版號。若更新比較小，例如只是除蟲（bug fixing），則會更新build的版號，這裏的build版本號通常可以和源碼管理工具的revision版本號對應起來，這樣可以把應用程序和相對應的代碼關聯起來，在進行bug查找或修正時是個很大的便利。
小知識:在windows下利用svn的TortoiseSVN工具subwcrev.exe可以很容易獲取代碼的revision，配合vs的腳本工具可以很容易的寫入程序中。 在linux環境下使用svnversion命令即可。
