談一談APP版本號碼問題

標籤：param   開發   ide   答案   order   基於   版本過低   bsp   參數   

如題：談一談APP版本號碼問題

為什麼要談這個問題，周五晚上11~12點，被點名，說APP有錯，無效的版本號碼，商城無法下單。
我正在準備收拾東西，周末回老家，結果看到這樣問題，菊花一緊。
我擦，我剛加的版本號碼檢查，在加版本號碼檢查前，我還跟統計的妹妹仔細核對了近半年來所有的版本號碼，怎麼還會有問題。
趕緊查，原來結果，看到了一個g1_2.5.5_65，在我的一再追問下說這個就是2.5.5的版本號碼。
然後咱們來說一說為什麼要加版本號碼檢查，然後再說，為什麼會加出問題來，最後在討論一下版本號碼規則。
題外話跟大家探討一下version這樣的參數怎麼傳遞比較合理。

首先在APP發版過程中，由於新的版本上有新的功能，有些需要和老的版本做相容，所以非常有可能伺服器端需要知道APP的版本號碼，
而伺服器在升級服務和自己的API也一定有版本號碼的概念，雖然很多時候我們可能注意不到，但是版本號碼這個一定是雙方互相都存在的。
我就是在這樣的一個情景下，我們的新的功能要同時需要相容新的老的APP，所以伺服器需要知道所有APP的版本號碼，這是需要APP傳給服務的參數。
同時伺服器也需要在基於某個版本號碼比如2.8.5做版本號碼大小的判斷。
比如說小於2.8.5的版本號碼，那麼就是老的邏輯，而大於等於2.8.5的版本就是新的邏輯。這可能是基於版本號碼的最簡單的相容邏輯了。

到這裡有心的讀者一定看出了說為什麼加個版本號碼也會加出問題來了，對這就是加個版本號碼檢查也加出問題的原因。
我在加檢查前，不確定我們的版本號碼的規則，然後我找統計妹妹仔細統計了近半年的所有的版本號碼，得到的結果是我們的版本號碼是x.x.x這樣的號碼，
x一定是數字，那這麼看來沒有問題，我就按這個規則解析比較，結果當遇到上邊看到的g1_2.5.5_65這個版本號碼時，直接numberformatexception.
還好，我們的處理非常之果斷，在版本檢查時出裡任何異常，都提示使用者版本過低，讓使用者升級。
但同樣暴露出了我們很多的問題，我們的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版本號碼問題