作為移動端產品經理，經常會做APP版本迭代規劃，所以不可避免的需要給APP版本確定版號的工作，大多數情況下可能都是拍腦袋確定的版本號。

有些公司可能會有專門的項目經理負責版本管理和版本號的命名，但是絕大多數小公司可能都是產品經理來做這項工作。

在網上搜集了一些資料，才發現APP版本號的命名是有很多規范和原則的，本文就將這些規范和原則分享給各位。

一、為什么要規范APP版本號的命名?

首先需要說明的是哪些人員需要用到APP版本號，第一是產品經理，第二是開發人員，第三是項目經理，第四是用戶。

對于產品經理，APP版本迭代基本都是有產品經理發起的，因此很多情況下都是產品經理在進行需求管理和版本規劃的時候就大體上劃分了版本號，版本號對于產品經理來說可以更好更清晰地篩選和確定每個版本的需求。

對于開發人員，版本號是直接和代碼相關的，很多時候不同版本交叉開發，同一時間可能在開發不同版本，為了保障代碼的規范和清晰，避免不同版本出現交叉混亂，版本號是極其重要的一環。

對于項目經理來說，版本號是需求管理中唯一標識符，需要根據版本號去管理和分配下發工作，同時也為了在軟件產品生命周期中更好的溝通和標記。

對于用戶來說，盡管版本號對于用戶來說只是一串數字，但是版本號給用戶的感知是不斷更新的數字，可以通過版本號來判斷自己的APP是不是最新的。

二、APP版本號的組成與規范

目前很多情況下，版本號可能只遵循了兩個原則和規范，即版本號是唯一的，且是一串數字這個基本原則。

在介紹APP版本號的命名規范和原則之前，我們首先需要了解一些APP版本號的組成是怎樣的。

軟件版本號有四部分組成：<主版本號.><子版本號>.<階段版本號>.<日期版本號加希臘字母版本號>

希臘字母版本號共有5種：base、alpha、beta、RC、Release。 例如：2.1.0.181209_Release。

下面對希臘字母版號進行簡述：

• Alpha版：也叫α版(開發環境)，此版本主要是以實現軟件功能為主，通常只在軟件開發者內部交流;
• Beta版：此版本相對于α版已經有了很大的改進，消除了嚴重的錯誤，但還是存在著一些缺陷，需要經過多次測試來進一步消除，此版本主要的修改對像是軟件的UI;
• RC版：此版本已經相當成熟了，基本上不存在導致錯誤的BUG，與即將發行的正式版相差無幾，測試人員基本通過的版本;
• Release版：此版本意味著“最終版本”、“上線版本”，在前面版本的一系列測試版之后，終歸會有一個正式版本，是最終交付用戶使用的一個版本。該版本有時也稱為標準版。一般情況下，Release不會以單詞形式出現在軟件封面上，取而代之的是符號(R)。

而對于絕大多數APP來說，一般采用的基本都是GNU風格的版本號管理策略，APP完全版本號的組成包括三組數字“<主版本號.><子版本號>.<階段版本號>”，也即X.Y.Z，其中X、Y、Z都為正整數。

三、APP版本號的命名修改規則

1. 主版本號

• 當APP的多個主要模塊有較大的變動，一般情況下，比方說APP新增一個TAB，整個產品結構都改變了;或者新增了新的功能或業務，比方說微信上線錢包，抖音上線直播;
• 主版本號起始值為0或者1，具體需要由產品經理來決定是否需要修改主版本號(PS：大多數可能需要老板拍板)。

2. 子版本號

• 子版本號初始值為0;
• 當APP的較少主要模塊發生較大的變動或新增模塊(涉及主邏輯變更的)、較多個分支模塊發生較大的變動或新增，相對于主版本號而言僅是局部的變動，比方說某個功能上的UI重構，某個頁面的優化等，其中較少模塊和較多模塊需要去定義，一般我們認為較少為小于3個，較多認為是超過3個;
• 子版本號的最大值需要確定，不同的公司可能有最大的值，比方說最大為9，如果超過9，則需要主版本號進1，也有些公司可能不存在最大值，只會在主版本號+1的情況下才會將子版本號歸0;這里沒有確定的原則和規范，可以由產品經理自己定規則。

3. 階段版本號

• 階段版本號初始值為0;
• 什么時候修改階段版本號，一般是Bug修復、較少個分支模塊的變動，比方說視覺、樣式、交互、文案等修改的情況;
• 一般情況下，如果只是修復bug，則階段版本號+1即可;如果既涉及到bug修復，又涉及到較少分支模塊的修改，則階段版號+2;如果超過3個分支模塊的修改，則建議直接子版本號+1。

總結

盡管說版本號只是一串數字，但是對于產品經理、開發人員以及用戶來說，都是有意義的一串數字。既能規范版本的生命周期，也能方便內部人員的溝通和工作。

拍腦袋去命名版本號是一個不嚴謹和規范的，而產品經理是需要去追求完美的，希望以上的APP版本的命名規范能夠給大家一些參考。