軟件版本號是一個軟件產(chǎn)品的重要組成部分吞滞，規(guī)范的版本號不僅僅可以標(biāo)識產(chǎn)品開發(fā)階段揉抵、功能更新秘狞、還能區(qū)分產(chǎn)品部署環(huán)境。上線發(fā)布的版本還能提示給用戶提供版本更新信息肯夏，產(chǎn)品功能更新內(nèi)容等信息经宏，引導(dǎo)及刺激用戶下載更新。
對于常見的軟件產(chǎn)品驯击，通常采用GNU風(fēng)格三段式版本號烁兰，即Major. Minor. Patch。用數(shù)值表示版本號徊都，數(shù)值之間用小圓點“.”分隔沪斟。如圖1所示
Major：表示大版本號，一般當(dāng)產(chǎn)品出現(xiàn)重大更新暇矫，重寫或者不再向后兼容的情況時主之，版本號會在Major上加1择吊，當(dāng)Major的值為0的時候，我們一般認(rèn)為產(chǎn)品處于開發(fā)或測試階段槽奕。當(dāng)Major增加1時我們會把后面的Minor.Patch清零几睛。
Minor：表示次版本號，當(dāng)產(chǎn)品有功能更新或者小的功能迭代和調(diào)整時史翘，版本號會在Minor上加1枉长。同理當(dāng)Minor增加1時，也會將后面的Patch清零琼讽。
Patch：表示修訂號或補丁號必峰，當(dāng)產(chǎn)品修復(fù)了一個bug或者頁面UI布局調(diào)整時，版本號會在Patch上加1钻蹬。
注意版本號不是逢10進1的吼蚁，比如當(dāng)Patch的值等于10時，版本號的Minor不加1问欠，而是寫成Major.Minor.10肝匆，如果產(chǎn)品再有迭代和更新，那么版本號更新為Major.Minor.11顺献。
有時在這種三段式的版本號之后旗国，還有Alpha版、Beta版這樣的先行版本號注整。這些先行版本號是當(dāng)產(chǎn)品要發(fā)布大版本或者核心功能時能曾，但是不能保證這個版本的功能100%正常可用肿轨，這個時候就需要發(fā)布先行版本寿冕。比較常見的先行版本包括：內(nèi)測版、公測版椒袍、RC 版和GA版等驼唱。
Alpha版是內(nèi)部測試版，書寫規(guī)范如：1.0.0-alpha.0驹暑，1.0.0-alpha.1玫恳。此版本表示軟件在此階段主要是以實現(xiàn)軟件功能為主，通常只用在軟件開發(fā)者內(nèi)部交流优俘，一般不向外部發(fā)布纽窟。該版本軟件的 Bug 較多，需要繼續(xù)修改兼吓。因為α是希臘字母的第一位臂港，表示最初級的版本。
Beta版是公測版，書寫規(guī)范如：1.0.0-beta.0审孽，1.0.0-beta.1县袱。此版本表示軟件在此階段該版本相對于Alpha版已有了很大的改進，消除了嚴(yán)重的錯誤佑力，但還是存在著一些缺陷式散，需要再經(jīng)過多次測試來進一步消除，這個階段的版本會一直加入新的功能打颤。該版本通常由軟件公司免費發(fā)布暴拄，用戶可從相關(guān)的站點下載。通過一些專業(yè)愛好者的測試编饺，將結(jié)果反饋給開發(fā)者乖篷，開發(fā)者再進行有針對性的修改。該版本不適合一般用戶安裝透且。
Release.Candidate即RC版撕蔼，是發(fā)行候選版，書寫規(guī)范如：1.0.0-rc.0秽誊，1.0.0-rc.1鲸沮。此版本的軟件產(chǎn)品和Beta版最大的差別在于Beta版會一直加入新的功能，但是到了RC版幾乎就不會加入新的功能了锅论。RC版是經(jīng)過測試人員測試基本通過的版本讼溺，主要著重于排錯和體驗優(yōu)化。RC版是最終發(fā)布給用戶使用的最接近正式版的版本最易，改正bug發(fā)行后就是正式版了怒坯，可以說是正式版之前的最后一個測試版。
Release即R版耘纱，是發(fā)行版敬肚。Release不會以單詞形式出現(xiàn)在軟件封面上毕荐，取而代之的是符號（R)束析。該版本意味“最終版本”，在前面版本的一系列測試版之后憎亚，發(fā)布的一個正式版本员寇，是最終交付用戶使用的一個版本，該版本有時也稱為標(biāo)準(zhǔn)版第美。
對于軟件開發(fā)人員蝶锋，版本號是直接和代碼相關(guān)的，很多時候不同版本交叉開發(fā)什往，同一時間可能在開發(fā)不同版本扳缕，為了保障代碼的規(guī)范和清晰，避免不同版本出現(xiàn)交叉混亂，版本號規(guī)范是極其重要的一環(huán)躯舔。對于項目經(jīng)理來說驴剔，版本號是需求管理中唯一標(biāo)識符，可以根據(jù)項目版本去管理和分配工作粥庄，跟進項目進度丧失，避免項目管理混亂，提升效率惜互。
在當(dāng)前的互聯(lián)網(wǎng)產(chǎn)品快速迭代的背景下布讹，很多公司，特別是小型技術(shù)團隊都喜歡使用敏捷開發(fā)的方式训堆，快速的產(chǎn)品迭代必定會導(dǎo)致產(chǎn)品需求描验、開發(fā)、測試蔫慧、上線各個時間線交錯在一起挠乳。如果沒有良好的版本規(guī)范，往往會出現(xiàn)姑躲，產(chǎn)品經(jīng)理不清楚現(xiàn)在這一版的哪些功能有沒有做睡扬；開發(fā)人員不知道這一版本應(yīng)該做哪些功能；測試人員不知道現(xiàn)在在測試的是哪個版本黍析；項目經(jīng)理無法通過版本號就知道現(xiàn)在項目處于哪個階段卖怜。要解決這些問題，規(guī)范的版本管理或許能提供一些幫助阐枣。
首先马靠，先來看一個軟件生命周期模型，改進版瀑布模型蔼两。如圖2
現(xiàn)在的軟件產(chǎn)品已經(jīng)不可能是經(jīng)典的瀑布模型就能解決的了甩鳄，項目人員往往都是需求改進、開發(fā)额划、測試等幾個過程循環(huán)迭代進行妙啃。往往開發(fā)人員上一版本的功能需求還沒有做完，就接到下一個版本的功能需求俊戳。如果產(chǎn)品功能復(fù)雜揖赴，產(chǎn)品需求規(guī)劃不清晰，特別是有多個產(chǎn)品經(jīng)理參與同一個項目的時候抑胎，往往會需求規(guī)劃不明確燥滑，任務(wù)劃分不清晰，導(dǎo)致開發(fā)人員分不清輕重緩急阿逃，甚至分不清哪一版到底該做哪些功能铭拧。這時赃蛛，需要需要產(chǎn)品經(jīng)理做好產(chǎn)品規(guī)劃，明確哪一個版本做哪些功能搀菩。比如目前產(chǎn)品已經(jīng)上線1.0版本焊虏，在1.1版本就做多優(yōu)惠券模塊，然后明確拼團模塊放到到1.3版本秕磷。如果有時間诵闭，產(chǎn)品暫不上線，繼續(xù)迭代更新澎嚣。千萬不要出現(xiàn)疏尿，如果可以，如果有時間易桃，就把拼團模塊一起做了吧這樣模棱兩可的產(chǎn)品規(guī)劃褥琐，導(dǎo)致開發(fā)人員都不知道到底做不做這個尷尬。軟件開發(fā)不像其他工作晤郑，它必須是一個明確的敌呈，沒有模棱兩可的工作。
關(guān)于軟件的開發(fā)和部署環(huán)境造寝，最少都得區(qū)分開發(fā)環(huán)境磕洪、測試環(huán)境、正式環(huán)境3種诫龙。如圖3所示析显，這樣子能夠有效避免項目部署混亂，減少服務(wù)之間的干擾和影響签赃，同時規(guī)范項目版本管理谷异，確保產(chǎn)品安全和服務(wù)穩(wěn)定。
項目開發(fā)時锦聊，各端開發(fā)人員在開發(fā)過程中歹嘹，自行管理維護開發(fā)版本號，如：dev-0.0.1孔庭，dev-1.2.3尺上。各端維護自己的代碼版本號，是不是就能隨意定版本號了呢史飞？答案肯定是否定的尖昏。關(guān)于產(chǎn)品版本號仰税，在團隊中一般由項目經(jīng)理或產(chǎn)品經(jīng)理根據(jù)產(chǎn)品迭代的功能進行確定构资，一般情況下，項目經(jīng)理或產(chǎn)品經(jīng)理只需要明確下一版產(chǎn)品的版本號前兩位陨簇，也就是Major. Minor吐绵，最后一位Patch由開發(fā)人員自行維護迹淌。為什么需要這樣做呢？我們知道己单，現(xiàn)在的軟件產(chǎn)品唉窃，如果基于B/S架構(gòu)的，都是由服務(wù)端+客戶端組成纹笼，往往服務(wù)端同時為多個客戶端（包括app纹份、web、小程序等）提供服務(wù)廷痘。產(chǎn)品部署上線時蔓涧，往往需要C端和服務(wù)端同時部署更新，只有前后端版本號統(tǒng)一笋额，才能明確上線版本元暴。但是在實際開發(fā)測試過程中，每個端都有需要進行代碼調(diào)整和bug修復(fù)兄猩，這些小的改進或者bug修復(fù)茉盏，就在各個端自行維護的Patch版本號體現(xiàn)即可。如圖4所示
項目提測時枢冤，開發(fā)人員提取出要測試的代碼版本鸠姨，將dev前綴改為test，如test-0.0.1淹真，test-1.2.3享怀，并由項目經(jīng)理或產(chǎn)品經(jīng)理統(tǒng)一統(tǒng)籌部署測試版。開發(fā)人員千萬不要改了一個bug就隨意提測一版趟咆，在項目開發(fā)過程中添瓷，我們往往會發(fā)現(xiàn)，在測試人員測試出問題值纱，提交bug之后鳞贷，還沒等測試人員測試完一遍，開發(fā)人員就迫不及待地修改bug虐唠，然后又直接部署提測搀愧。這樣的操作，往往導(dǎo)致了很多問題疆偿，如測試人員根本不知道自己測試的哪一個版本咱筛；之前測試出的bug，在對接時無法復(fù)現(xiàn)杆故；bug沒有等回歸迅箩，就被覆蓋掉；沒有統(tǒng)一統(tǒng)籌提測处铛，各端自行提測時饲趋，還會出現(xiàn)前端部署了后端沒部署導(dǎo)致產(chǎn)生bug的情況拐揭。同時這樣子不規(guī)范的版本管理，也加劇了項目的混亂程度和管理難度奕塑，增加項目風(fēng)險堂污。
項目部署上線時，開發(fā)人員只需要提取出上線代碼龄砰，將部署環(huán)境切換為正式服盟猖，同時在打版本號，將版本改為v開頭换棚，如v-1.0.0扒披，v-1.2.3。然后在項目經(jīng)理或產(chǎn)品經(jīng)理統(tǒng)籌下圃泡，各端部署正式服即可碟案。當(dāng)然，如果項目進行大版本修改或者大功能更新颇蜡，也可以發(fā)行先行版价说，征集更多意見和測試反饋，確保產(chǎn)品質(zhì)量和用戶體驗风秤。
版本號的是軟件的一個重要組成部分鳖目，也是軟件項目管理的重要內(nèi)容，在項目開發(fā)和管理過程中缤弦，定義良好的軟件版本規(guī)范领迈，做好軟件版本管理，能夠規(guī)范項目管理流程碍沐，明晰項目需求和跟進開發(fā)進度等狸捅，避免項目管理混亂，減少隱藏bug累提，提高效率尘喝。同時也能更好地保證項目質(zhì)量，降低項目風(fēng)險斋陪。
