談一談APP版本號問題
如題：談一談APP版本號問題
為什麽要談這個問題，周五晚上11~12點，被微信點名，說APP有錯，無效的版本號，商城無法下單。
我正在準備收拾東西，周末回老家，結果看到這樣問題，菊花一緊。
我擦，我剛加的版本號檢查，在加版本號檢查前，我還跟統計的妹妹仔細核對了近半年來所有的版本號，怎麽還會有問題。
趕緊查，原來結果，看到了一個g1_2.5.5_65，在我的一再追問下說這個就是2.5.5的版本號。
然後咱們來說一說為什麽要加版本號檢查，然後再說，為什麽會加出問題來，最後在討論一下版本號規則。
題外話跟大家探討一下version這樣的參數怎麽傳遞比較合理。
首先在APP發版過程中，由於新的版本上有新的功能，有些需要和老的版本做兼容，所以非常有可能服務器端需要知道APP的版本號，
我就是在這樣的一個情景下，我們的新的功能要同時需要兼容新的老的APP，所以服務器需要知道所有APP的版本號，這是需要APP傳給服務的參數。
同時服務器也需要在基於某個版本號比如2.8.5做版本號大小的判斷。
比如說小於2.8.5的版本號，那麽就是老的邏輯，而大於等於2.8.5的版本就是新的邏輯。這可能是基於版本號的最簡單的兼容邏輯了。
到這裏有心的讀者一定看出了說為什麽加個版本號也會加出問題來了，對這就是加個版本號檢查也加出問題的原因。
我在加檢查前，不確定我們的版本號的規則，然後我找統計妹妹仔細統計了近半年的所有的版本號，得到的結果是我們的版本號是x.x.x這樣的號碼，
還好，我們的處理非常之果斷，在版本檢查時出裏任何異常，都提示用戶版本過低，讓用戶升級。
但同樣暴露出了我們很多的問題，我們的APP經過兩年多的發版竟然從來沒有統一過版本號，甚至規則都沒有統一過。
再次追問下去，說由於不同的下載渠道和推送渠道，我們會寫上不同的版本號，這個答案的結果我當然不滿意。
心中多是無奈也沒有辦法，於是乎推進版本號趕緊統一，至少在規則上能有一個可以統一解析的規則。
這裏的一個事情做得好的就是至少我們還有版本號，無論當時服務器使用沒有使用版本號，至少APP是傳了的。
那麽這裏就引出了第三個問題，版本號的規則問題，關於這個問題，我不想深入探討和研究。
百度“軟件開發版本號規則”或者“軟件開發版本號命名規範”講的非常之詳細，非常明白，很容易理解。
我想說的無論怎麽樣一定要指定一個自己可以統一解析的規則和規範，只要按照規則和規範一定能很好的處理版本號。
我比較推薦的使用的版本號有兩種，
1是：主版本號.次版本號.修訂版本號.日期版本號
2是：主版本號.次版本號.修訂版本號.構建版本號
這樣的一組號碼，清晰明了，足夠用了。
最後談一談版本號怎麽傳遞比較合適，首先我們不說APP，我們做服務器端開發特別是RESTAPI時一定也遇到過說一個API的version問題，
網上不同的人有不同的見解，不同的網站有不同的實現方式，我說一下我知道的常見的幾種方式：
1、在http header中傳遞，例如：header.set("version","2.8.5")
2、在使用url path的方式，例如：/www.xxx.com/order/v2.8.5/create
3、使用url query paramter的方式傳遞，例如：/www.xxx.com/order/create?v=2.8.5
4、使用form表單提交version，(這個貌似極其少見)例如：<form method="post|get" action="/order/create"><hiden name="version" value="2.8.5"/>...</form>
這個明白了之後那麽APP給服務器傳參，也無外乎這幾種方式，具體使用哪種中方式可以根據自己的喜好而定。
貌似我在某一篇文章中看到說雖然使用url path的方式比較直觀，有些大型的網站也在使用，但是REStful的規範說要在header中使用version才算正統。
這個就無所謂了，我感覺都行，之前老大還跟我爭執過這個，我說要加在url path中就是使用第二種方式，結果老大不同意，說你這樣將來要維護一堆的url,v1,v2會很麻煩。
說推薦第一種，我比較固執的按第二種方式做了，後來另一個同事也討論起這事，所就按第二種方式比較好，這裏老大的態度變了，說啥啥啥公司都是第二種，咱們也第二種吧，
我心裏那個委屈，特麽，我早跟你說，你跟我還爭個毛線，我做都做了，還在我傷口上撒鹽。我跟老大爭這些是不是將來做不了老大，悲催。
現在想想第三種也非常棒，真的也非常不錯的。
好了今天，關於版本號討論就說這麽些吧。
歡迎大家評論發表意見或提出問題
談一談APP版本號問題