最初 KKTOWN 是以 Jenkins 建置編號(單一數字遞增)當作團隊內溝通的依據，因為它數字單一不會重複，但每當開發進到 QA 階段就會有需要手動調整版號的事情會發生。

當問題重複發生時，代表流程有可以改進的空間。

原有開發流程

我們使用的是 JIRA 作為軟體開發管理工具，並以敏捷開發 Scrum 為開發方法，兩週一個 Sprint 。在 Planning metting 會規劃好 Sprint 要完成的工作，並在每張票上填上版本號。在一開始我們是使用 Master 分支的 Jenkins 建置編號 ，所以我們可以知道下一個版本號是什麼而預先填上。

多次手動移票

因為建置編號是會隨著 Merge request 遞增的，所以當開發進到 QA 期間被測出 Bug 時，我們會不斷的快速修正，此時建置編號也隨之增加。那麼問題就來了，每當進一次建置編號就要有人(RD 或 QA)去手動更新 JIRA 上的版本號，如果 Bug 來來回回修正，手動修改的部分就會很惱人。

這個情況還會發生在兩個 feature 要交換版本上線時，假設 feature A 250 而 feature B 251，因為某些原因要把 B 往前移

就要先把 B 改成 252
再把 A 改成 251
再把 B 改為 250

功能落在哪一版

除了原有開發流程會卡卡的以外，每當有任何人問某某功能在哪一格版本發佈，就必須回到 JIRA 上查找重新對應，那時常聽到的對話如下：

QA: 錄影功能是哪一版?
RD: 你問的是哪一個平台?
QA: iOS
RD: OK, 是 iOS 256 版

版本號制定原則

這才意識到我們沒有明確定義版本號，那又應該怎麼訂呢?

原則上我們已經知道 app 的版本號大概是長這樣 version 1.3.5， 也就是 {major}.{minor}.{hotfix} ，而我們最後將這三種不同等級的版號定位如下：

1. Major: 功能新增會影響舊版使用者 > 強制更新
2. Minor: 功能新增不影響舊版使用者 > 建議更新
3. Hotfix: 單純修 bug 或文字修改

這也延伸出 Android/iOS 版本號是否要同步的問題，而我的建議是要同步。因為這樣在規劃時可以很明確的設定版本 2.1.0 要做什麼事情，不論是哪一個平台。

接著馬上有人問，那如果有一些是平台獨有的功能應該怎麼辦? 很簡單，就另一個平台跳過那個版號就好，舉個例子：

1.1 錄影功能 android, ios
1.2 Android 改成 tab bar android
1.3 7-11 物流 android, ios

iOS 不需要實作 tab bar，所以做完 1.1 之後直接跳版號到 1.3

後記

之前也聽過其他人版號制定，比如說單號是內部使用，雙號外部發佈之類的，但每個團隊有自己的考量，所以也不一定要別人怎麼做我們就跟著做。

同理，這篇也是把我之前遇到的問題與解法跟大家分享，不一定要跟我們一樣喔！
歡迎大家留言討論，讓我們一起把軟體做得更好 😀