碼上歡樂
相關內容    簡體    繁體

App版本更新接口的設計

本文轉載自   查看原文   2019-05-10 20:18   993 

 

前段時間公司業務調整，新開了新的移動端的項目，所以和朋友聊到了“版本號”和“版本更新所需的數據表設計”。

一般來講大部分的軟件版本號分3段，比如 A.B.C

A 表示大版本號，一般當軟件整體重寫，或出現不向后兼容的改變時，增加A，A為零時表示軟件還在開發階段。 
B 表示功能更新，出現新功能時增加B 
C 表示小修改，如修復bug，只要有修改就增加C 

除了版本號之外還會有一些修飾的詞，比如： 
alpha: 內部版本 
beta: 測試版 
rc: 即將作為正式版發布 
lts: 長期維護 

但老實講，知名的項目沒有幾個是遵守上述規則的。 
商業軟件完全取決於老板的意思，有時候還會配合宣傳任意地來更改版本號。 
而歷史悠久的開源項目，往往會有自己的規則，例如Linux用奇數版本表示開發板，偶數版本表示正式版等等。 

隨着 Github 的出現，越來越多的人可以參與到貢獻開源代碼的活動中，版本號規則越來越混亂。 

Github 起草了一個具有指導意義的，統一的版本號表示規則，稱為 Semantic Versioning(語義化版本表示). 該規則規定了版本號如何表示，如何增加，如何進行比較，不同的版本號意味着什么。

除此之外，作為產品，日常工作涉及版本更新，更是家常便飯，尤其是安卓產品，面對碎片化的渠道，總有些蛋蛋的憂桑，所以一張可擴展的數據表顯得尤為重要。

起初我也有些凌亂，后來找朋友問了一下，具體如下：

checkversion | CREATE TABLE `checkversion` (

`id` int(11) NOT NULL,

`app_id` varchar(5) NOT NULL,  //各產品APP_ID

`app_name` varchar(20) NOT NULL, //各產品APP_名稱  

`client_version` varchar(20) NOT NULL, //客戶端版本號

`client_useragent` varchar(500) NOT NULL, //各渠道版本 ，以逗號分隔，可升級多渠道，全渠道用all，主要是區分多渠道的不同升級，比如騰訊某個渠道，並不讓你升級到最新版本，則就可以不加上騰訊渠道。

`client_useragent_name` varchar(100) DEFAULT NULL, //渠道名稱（防止泄露一般不填寫）

 `download_url` varchar(100) NOT NULL, //升級下載網址 

 `update_id` int(11) NOT NULL DEFAULT '0', //關鍵是這個字段，記錄本次版本應該升級到最新版本號，如本次為2，最新為3，則最新版本號的ID記錄為15，則填15， 最新的記錄則為0. 每一次APP升級請求API都會將低版本的記錄自動更新為3

 `update_log` varchar(500) DEFAULT '', //升級日志

 `update_install` int(11) NOT NULL DEFAULT '0' COMMENT '是否強制安裝', 

  PRIMARY KEY (`id`)

) ENGINE=MyISAM DEFAULT CHARSET=utf8   

再配上后台的自動或手動管理，就比較強大了，當然這個理解起來會有些別扭，但是使用起來卻是任你升級變化萬千，我都可以包容。

 

大家都知道，版本號一般由以下幾部分組成：

1. 主版本號
2. 次版本號
3. 修正版本號
4. 編譯版本號
例如：2.1.3 ，3.7.5，10.2.0
在比較版本號時，正確的做法應該是，主版本號和主版本號比較，次版本號和次版本號比較等等，也就是把版本號分割，對應的組成之間進行比較，如下：

/**
* 版本號比較
*
* @param version1
* @param version2
* @return
*/
public static int compareVersion(String version1, String version2) {
if (version1.equals(version2)) {
return 0;
}
String[] version1Array = version1.split("\\.");
String[] version2Array = version2.split("\\.");
Log.d("HomePageActivity", "version1Array=="+version1Array.length);
Log.d("HomePageActivity", "version2Array=="+version2Array.length);
int index = 0;
// 獲取最小長度值
int minLen = Math.min(version1Array.length, version2Array.length);
int diff = 0;
// 循環判斷每位的大小
Log.d("HomePageActivity", "verTag2=2222="+version1Array[index]);
while (index < minLen
&& (diff = Integer.parseInt(version1Array[index])
- Integer.parseInt(version2Array[index])) == 0) {
index++;
}
if (diff == 0) {
// 如果位數不一致，比較多余位數
for (int i = index; i < version1Array.length; i++) {
if (Integer.parseInt(version1Array[i]) > 0) {
return 1;
}
}

for (int i = index; i < version2Array.length; i++) {
if (Integer.parseInt(version2Array[i]) > 0) {
return -1;
}
}
return 0;
} else {
return diff > 0 ? 1 : -1;
}
}
結果說明：0代表相等，1代表version1大於version2，-1代表version1小於version2

通過此方法便可以直接進行android 版本號大小比較了,方法直接拿來用即可.
---------------------
作者：程大龍
來源：CSDN
原文：https://blog.csdn.net/qq_25749749/article/details/79847922
版權聲明：本文為博主原創文章，轉載請附上博文鏈接！

 

 

 

 

 

 

APP產品初期如何搭建簡單有效的版本管理機制

APP產品初期，往往需要快速迭代，小步快跑。那也就意味着不會有過多的時間進行詳細的APP版本規划。在該背景下，產品經理該如何搭建簡單有效的版本管理機制？

▎前言.APP版本管理結構

我們不追求非常嚴密的流程制度，那樣並不適合初創項目的節奏規律。對於初創項目，我們采取小步快跑的策略，將業務搭起來並順利跑通，是我們的首要目標！所以接下來我們討論的是如何搭建APP版本管理的"骨架"~

 
 

▎1.應用市場賬號及物料准備

1.1應用市場賬號

開發的APP最終是需要通過應用市場去推廣的，如Android的華為應用市場、iOS的APP Store。所以第一步，選擇應用市場；第二步，注冊開發者賬號。

選擇應用市場

不需要覆蓋所有的應用市場，只需要覆蓋主流的應用市場即可。

 
 

注冊開發者賬號

我們登錄各大應用市場的開發者網址后，申請企業開發者賬號，所需要的物料除了《營業執照》和公司的郵箱以外，其余的統統都根據注冊流程按部就班的填寫即可。當然，記住使用Excel備份：

 
 

1.2物料准備

物料准備就是實打實的體力活，但是這個體力活要做好不容易，比如到底需要准備什么物料，這些物料的規格要求又是怎么樣的，如何去落實和管理。我特意為大家整理了一份完整版物料表格，以該表格作為一份CheckList，事半功倍~

 
 

▎2."藍湖"設計協助平台搭建

一個APP必然會由眾多的頁面組成，也必然會有眾多的參與者，包括產品狗、設計屎、還有后來者。萬物多則亂之，而后亂則管之。我們借用"藍湖"產品設計在線協助平台來管理我們的頁面，並邀請不同模塊負責的團隊成員維護自己的頁面，給出簡單的交互與標注。

 
 

▎3.第三方數據服務接入/統計

數據分析是任何產品繞不開的一環，而目前市面上提供數據服務的供應商也比較成熟，可以選擇一家主流的，讓開發小哥哥接入其數據服務的SDK即可。如我目前所使用的第三方talkingData，通過其實現數據收集及基本的數據分析（累計用戶、新增用戶、版本使用分布、日活、留存等）。

 
 

▎4.APP迭代節奏制定

產品初期，往往需要快速迭代，小步快跑。所以我們制定的迭代周期是雙周。通過快速的迭代周期，快速校驗產品功能是否符合市場預期，或者功能優化是否有效。當然，迭代管理也是一門學問，涉及項目管理，我們不必過於深入。只要借助騰訊系的TAPD項目管理系統來協助我們完成即可。

 
 

▎5.應用市場提審策略

應用市場提審相當具有博弈性。

和誰博弈？和iOS應用市場的審核人員博弈（本質是和審核規則博弈）；博弈什么？博弈能否過審上架APP Store；為什么要博弈？沒辦法，APP Store具有巨大的流量資源，同時其對上架的要求非常高，主要體現在[資質]上。

言歸正傳，什么場景下我們需要重點關注應用市場的提審策略？當我們的業務涉及以下敏感業務時，需要重點關注提審策略：

①非持牌金融機構提供的金融服務，例如P2P借款、導流給其它網貸平台。

②訂閱、游戲內貨幣、游戲關卡、優質內容等虛擬充值類業務，例如Q幣充值、愛奇藝會員。

③提供真實貨幣的游戲、彩票或競猜活動，例如下注、撲克、一元購。

④涉及到假冒侵權的業務，例如A貨、未授權的大牌銷售。

如果涉及到上述的敏感業務，還想成功上架的話，那只有一招——巧妙的繞過去（騙審）。我們設計屏蔽邏輯，在審核期間與過審后采取不同的狀態：

 
 

▎6.應用市場ASO管理

這是一個輕松的話題，什么是ASO，無非就是應用市場的排名優化，提高曝光。那我們要如何做？很簡單，找人刷單。刷關鍵詞、刷評論、刷下載量。反正，給錢，大爺~

 
 

▎7.版本過程資料管理

這個也簡單，每個版本要把安裝包、原型稿、設計稿、交互稿、需求范圍列表等物料整理好，並在固定的文件夾保存好，作為公用資源即可。



作者：猩猩相嘻
鏈接：https://www.jianshu.com/p/a458c8c2e4ac
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯系作者獲得授權並注明出處。

 

 

App版本更新接口的設計

 

工作這幾年碰到的版本檢測升級的接口也算是五花八門，啥樣的都有，但肯定有的功能是有個apk的下載鏈接，能間接或直接提示你是強制還是非強制更新：

  • 間接是指提供你后台最新版本號，讓你自己與本地版本號通過比較得出是否升級或強制升級；
  • 直接就是后台接口直接返回個Boolean類型告訴你是強制或者非強制更新。

個人認為一個好的版本檢測接口需要設計的更靈活更清晰用起來更方便，下面就我理解的接口設計如下（如思路有誤，歡迎指正）：

總字段如下(並不是所有字段都要返回給客戶端)：
  1.最新版本號 ：newVersion 2.最小支持版本號 : minVersion 3.apk下載url : apkUrl 4.更新文案 : updateDescription 5.是否有更新 : isUpdate 6.是否強制更新 : forceUpdate 可選字段： 7.apk文件大小：apkSize 8.apk的文件MD5值：md5

方案一（前端處理邏輯）：
前端調用獲取當前服務器端最新版本信息的接口，然后根據返回的服務器端最新版本信息與客戶端當前版本信息進行比較，此處需要后端提供最新版本號 ：newVersion 、 最小支持版本號 : minVersion 、apk下載url : apkUrl 、更新文案 : updateDescription 這四個字段。如下表：

字段 字段描述
newVersion 最新版本號
minVersion 最小支持版本號
apkUrl apk下載url
updateDescription 更新文案

客戶端邏輯如下：

  1. 如果currentVersion < newVersion,則有更新信息；
    • 如果currentVersion < minVersion,則需要強制更新；
    • 如果currentVersion >= minVersion,則不需要強制更新;
  2. 如果currentVersion == newVersion，則沒有更新信息。

客戶端對應的流程圖：

 
更新處理邏輯放客戶端.png

前端處理邏輯不足之處：
對指定版本進行強制更新可能不是那么好，可是為什么要對指定版本進行更新呢？
此處做個假設：你的應用當前線上運行版本為V2.1.1, V2.1.2兩個版本用戶量比較多，又快要發布V2.1.3了，此時發現V2.1.2有個bug需要修復一下，然后在V2.1.3修復后發布了，當時感覺小問題就非強制更新（ 畢竟強制更新比較反感），過了幾天查看V2.1.1, V2.1.2版本的用戶量依然不減，升級的積極性不高啊，可是現在發現V2.1.2的這個bug風險很大，一旦出問題要卷鋪蓋走人的地步，那就要強制更新了，可又不想影響V2.1.1和V2.1.3版本的用戶（ 對強制更新比較反感），此時想到要是能對V2.1.2一個版本強制更新就好了。
備注：此場景只是一個假設，當然即便碰到這個假設，只要前期設計的合理都能解決，比如：

 

  • 后端說我再多返回一個字段forceUpdateList給你，內容為指定版本強制更新的版本號列表，只要當前版本在該列表中就強制更新。（此方案前端表示想哭）
  • 或者不想要強制更新的版本號列表也可以，給你個字段forceUpdateVersion表示需要強制更新的版本信息,用正則匹配，如果匹配到的版本號就強制更新。（前端能做，后端也能做，看誰能說服誰了）
  • 可能也有人會說熱修復或者插件化表示不擔心，那就繞過吧，此處目的是為了分析版本升級的最優方案。

方案二(后端處理邏輯)：
在客戶端請求參數中添加當前版本號currentVersion傳輸給后台，由后台根據客戶端傳過來的當前版本號currentVersion做相應的判斷后給出是否強制更新。
后端邏輯如下：

  1. 根據是否有特殊需求可指定某個版本必須強制更新，如currentVersion == XXX,則forceUpdate = true;
  2. 如果currentVersion < newVersion,則isUpdate = true；
    • 如果currentVersion < minVersion,則forceUpdate = true；
    • 如果currentVersion >= minVersion,則forceUpdate = false;
  3. 如果currentVersion == newVersion，則isUpdate = false.

后端邏輯對應流程圖：

 
更新處理邏輯放后端.png

 

結論：
返回客戶端的字段僅需要apk下載url : apkUrl、更新文案 : updateDescription、是否有更新 : isUpdate 、 是否強制更新 : forceUpdate 這四個字段即可。如下表：

字段 字段描述
apkUrl apk下載url
updateDescription 更新文案
isUpdate 是否有更新
forceUpdate 是否強制更新

總結：
細心的你可能會發現上面的可選字段apkSize和md5並沒有用到，既然是可選字段也就是可用可不用，根據需要決定是否采用，這里來講下他們的用處。

  • apk文件大小apkSize
    這個用處可以說出於考慮用戶體驗，需要在升級彈框出來展示給用戶將要更新的內容多大，讓用戶決定在非WIFI狀態是否要更新，不能為了拉用戶下載量或所謂的UV數直接讓用戶在不知道大小的情況下去直接下載（土豪用戶繞路）。
  • apk的文件MD5值
    這個主要是出於安全考慮吧，因為文件內容固定的話對應的md5是一樣的，我們可以通過這個md5值來和下載的apk的md5值進行比較去保證我們從服務器更新下載的apk是一個完整的未被篡改的安裝包，也就是說如果我們下載的apk的md5值和服務器返回的md5值相等，則說明我們下載的apk是完整的，且沒有被相關有心人處理過的apk。

綜上所述，這個版本更新的處理邏輯客戶端和后端誰來做都可以，無關乎懶不懶的問題，個人感覺靈活性后端比客戶端方便多了，當然客戶端也能做，只是客戶端做起來前期准備工作要考慮周全，各種場景都要考慮進去（還是會存在一些未知場景），不然只能下個版本實現了，考驗你設計能力的時候到了。以上純屬個人見解，如有更好的方案，歡迎指教。



作者：閑庭CC
鏈接：https://www.jianshu.com/p/f7394d871542
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯系作者獲得授權並注明出處。

 

 

Semantic Versioning 2.0.0

本文章翻譯自 https://semver.org/
中文版在這里 https://semver.org/lang/zh-CN/，但讀起來太困難。這里搞一版更教程化, 但又不失嚴謹的。

一個良好的版本號的結構與改動規則，向用戶傳達了我們軟件中改動的影響級別。
作者在這篇官方文檔里，給出了對 semver 的精准定義。

搬運正文

概述

給定一個版本號： MAJOR.MINOR.PATCH (主版本號.次版本號.補丁版本號)：

  1. 當你修改了 API，使其(與之前版本)不兼容時，遞增 MAJOR,
  2. 當你用向后兼容的方式加了些功能時，遞增 MINOR,
  3. 當你用向后兼容的方式解決了幾個 Bug 時，遞增 PATCH。

給 預發布版本 附加的標簽，以及與編譯相關的額外信息，可以作為 MAJOR.MINOR.PATCH 這種格式的擴展，加到版本號的后面。

引言

在軟件管理的世界里, 有個可怕的地方, 叫 "Dependency Hell"[1]. 你的系統規模增長的越大, 集成到系統里的軟件包越多, 你就越有可能發現, 某天, 你已經深深的陷入了這種絕望之地.

在那些有很多依賴包的系統里, 發布新的軟件包版本很快就會變成一個夢靨. 如果依賴要求太緊, 你可能會陷入 "版本鎖定" [2]. 如果版本要求太松, 你又不可避免的遭受"版本濫交"[3]之痛. [4]. 而所謂的 "Dependency Hell", 就是當 "版本鎖定" 和/或 "版本濫交" 阻止你簡單, 安全的推動項目前行的時候, 你的處境.

作為這個問題的一個解決方案, 我提議一套簡單的規則和要求, 以規定如何分配和增長版本號. 這些規定基於, 但不限於已經在各種閉源, 開源軟件中廣泛使用的普遍慣例. 要想這套理論奏效, 首先你得聲明一個公開的 API. API 可能是由文檔組成的, 也可能是直接使用代碼實現的. 但不管怎樣, 重要的是這個 API 是清晰和精確的. 一旦你確定了你的 API, 使用增加特定的版本號的方式, 來傳達 API 的改動. 考慮一個 X.Y.Z (MAJOR.MINOR.PATCH) 的版本號格式: 那么, 不影響 API 的Bug修復: 遞增補丁版本號Z; 向后兼容的 API 的添加或修改: 遞增次版本號; 不向后兼容的 API 的修改: 遞增主版本號.

這套理論我稱作 "Semantic Versioning", 那些個版本號以及他們的改變傳達着與 底層代碼, 以及從一個版本到另一個版本改了什么 相關的含義.

Semantic Versioning 規范

  1. 使用 Semantic Versioning 的軟件 必須 聲明一個公共的 API. 這個 API 可能是定義在代碼里的, 或者僅僅存在於文檔里, 不論用什么方式實現, 它都必須精確而全面.

  2. 一個正常的版本號必須使用 X.Y.Z 的格式, 其中 X, Y, 和 Z 都是非負的整數, 並且 必須不能 包含前導零.
    X 是主版本號, Y 是次版本號, 而 Z 是補丁版本號. 每個元素都必須以數字的方式遞增. 舉例: 1.9.0 -> 1.10.0 -> 1.11.0.

  3. 一旦一個打了版本的包被發布出去了, 那個版本的內容就 不能 再修改了. 任何修改 必須 作為一個新的版本重新發布.

  4. 主版本為零 (0.y.z) 的版本, 是用作初始開發階段的. 任何東西都可能在任意的時間被更改. 這時候我們不應該認為它的 API 是穩定的.

  5. 1.0.0 版本表明對外公開 API 的形成. 從此之后, 版本號的遞增方式取決於這個公開的API, 以及它如何修訂.

  6. 補丁版本號Z (x.y.Z | x > 0) . 如果只有向后兼容的bug修復被引入的化, 補丁版本號 Z 必須 遞增. "Bug修復"是指一個修正錯誤行為的內部修改.

  7. 次版本號Y (x.Y.z | x > 0). 如果一個新的, 向后兼容的功能被引入到了公開 API 里, 次版本號 必須 遞增. 如果公開 API 的任何功能被標記為 "已棄用的", 次版本號 必須 遞增. 如果大量的新功能或改進被引入到私有代碼里的時候, 次版本號 可以 遞增. 次版本號的改變 可以 包含補丁級別的改動. 當遞增了次版本號的時候, 補丁版本號 必須 清零.

  8. 主版本號X (X.y.z | X > 0). 如果任何的向后不兼容的改動被引入到了公開 API中, 主版本號 必須 遞增. 它的遞增 可以 包含次版本和補丁級的改動. 當主版本號遞增時, 次版本號和補丁版本號 必須 清零.

  9. 一個預發布版本 可以 通過在補丁版本號后面追加一個短線, 以及一系列的用點分割的標識符 來描述. 標識符 必須 僅包含 ASCII 的 阿拉伯數字和短線 [0-9A-Za-z-]. 標識符 必須不 為空. 數字標識符 不能 包含前導零. 預發布版本比對應的正常版本的優先級要低. 預發布版本表明, 它不穩定, 並且可能不滿足其對應的正常版本所預定的兼容性要求. 例子: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

  10. 編譯時的附加信息, 可以 通過在補丁版本號后面追加一個加號, 以及一系列的用點分割的標識符 來描述. 標識符 必須 僅包含 ASCII 的 阿拉伯數字和短線 [0-9A-Za-z-]. 標識符 必須不 為空. 在比較版本優先級的時候, 編譯附加信息 應該 被忽略. 因此, 兩個只有編譯附加信息不同的版本, 具有相同的優先級. 編譯附加信息的舉例: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.

  11. 優先級是指在排序的時候怎樣比較不同的版本. 計算優先級的時候, 必須 將版本號以 "主版本號", "次版本號", "補丁版本號", "預發布標識符" 的順序拆分. 優先級取決於, 在從左至右依次比較這些個標識符的時候, 發現的第一個差別. "主版本號", "次版本號", "補丁版本號" 總是以數字的方式參加比較. 舉例: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1.
    當"主版本號", "次版本號", "補丁版本號" 都相同的時候, 預發布版本比正常的版本優先級要低. 舉例: 1.0.0-alpha < 1.0.0.
    如果兩個預發布版本有相同的 "主版本號", "次版本號", "補丁版本號", 優先級就 必須 通過比較點分割的標識符來確定, 從左至右依次比較, 直到發現一個不同: 只有數字的標識符號以數值高低比較, 有字母或連接號時則逐字以 ASCII 的排序來比較. 數字的標識符號比非數字的標識符號優先級低. 若開頭的標識符號都相同時, 字段比較多的預發布版本號優先層級高. 舉例: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.

為什么使用 Semantic Versioning ?

(我的這套理論) 並不是什么新的或者革命性的點子，實際上，很可能你已經做了些很接近這個的工作。但問題在於，僅僅是“接近”並不夠。如果不遵守有點兒"官方"的協定，版本號對於管理依賴來說基本沒什么用。通過給我上面的思想命名，並給予其清晰的定義，將你的意圖傳達給你的軟件的用戶就變得很簡單了。一旦意圖清晰明了，最終一個靈活的(但也不是過於靈活的)軟件依賴要求就可以搞定了。
我們可以通過一個簡單的例子，展示一下 Semantic Versioning 可以讓 “Dependency Hell” 成為歷史。考慮一個叫做 “消防車” 的版本庫，他需要一個使用了 Semantically Version 的軟件包 “梯子”。當 “消防車” 剛創建的時候，“梯子”在3.1.0 版本。因為“消防車”使用了 “梯子” 3.1.0 新引入的功能，你可以簡單的指定，你的“消防車” 對“梯子”的依賴要求是：大於等於 3.1.0 ，但小於 4.0.0 。現在，梯子 "3.1.1" 和 "3.2.0" 好了，你可以把他們發布到你的軟件包管理系統，並且你知道他們跟現有的、跟它有依賴關系的包是兼容的。
作為一個負責人的開發者，你當然想驗證任何軟件包升級都是正常的、跟你宣傳的一樣。但現實世界是一團亂麻，對此我們除了小心再小心之外沒有更好的辦法。你能做的，是讓 “Semantic Versioning” 提供你一個合理的方法去發布、升級軟件包，而不必去搞許多新版的依賴包，節省了你的時間，免去了許多麻煩。
如果所有這些聽起來挺給力的，要開始使用 “Semantic Versioning” 的話，你只需要聲明你正在這么搞，然后遵守這些規范就好了。把這個網站鏈接到你的 README 文檔里，以便其他其他人也可以了解這些規則，並從中受益。

FAQ

  • 在初始開發階段，怎么去處理 0.y.z 的版本號？
    一個簡單的做法是， 使用 0.1.0 作為第一版初始開發版本號，然后為隨后的發布包遞增次版本號(minor version)
  • 我怎么知道什么時候發布 1.0.0 版？
    如果你的軟件已經在生產環境了(已經上線了), 很可能已經 1.0.0 了。如果你做好了一個 從此用戶可以信賴的、穩定的API版本，你應該發布1.0.0。如果你正為向后兼容的事情心煩，你應該早就 1.0.0 了。
  • 這東西難道不會阻撓快速開發、快速迭代嗎？
    為零的主版本就是為了快速開發的。如果你每天都在改 API，你要么還在 0.y.z，要么在另外一個開發分支上，為下一個主版本做准備。
  • 如果，哪怕是微小的 API 的不兼容改動，主版本都要蹦，我豈不是很快就到 42.0.0 版了？
    這是個關於為開發負責，以及前瞻性的問題。在有許多代碼依賴之的軟件中，不應該輕率的做不兼容的改動。升級招致的代價可能是相當大的。不得不通過遞增主版本號來發行不兼容的改版，意味着你將充分考慮改動所帶來的影響，並且評估所涉及的 成本/收益 比。
  • 整理個 API 的文檔太費事兒了！
    為供他人使用的軟件編寫適當的文件，是你作為一名專業的開發者應盡的職責。“管理項目復雜度” 是保持項目高效的非常重要的一部分，而如果沒有人知道如何使用你的軟件，或者不知道哪些函數可以放心的調用的話，就不好做。Semantic Versioning，以及對 良好定義的API 的堅持，可以讓每個人、每件事情都順利進行。
  • 要是我不小心把一個不向后兼容的改動當成一個次版本號發布了怎么辦？
    一旦發現你破壞了 Semantic Versioning 規范，馬上解決這個問題，然后發布一個新的次版本，以恢復向后兼容。即使在這種情況下，直接修改已經發行的版本也是不可接受的。如合適，在文檔里寫明這個有問題的版本，並將這個問題告知你的用戶，以便用戶知曉這個出問題的版本。
  • 如果我在沒有更新API的前提下，更新了我自己(軟件)的依賴，應該怎么做？
    由於沒有影響到公共 API，這將被當做是兼容的。那些使用了跟你一樣的依賴包的軟件，應該也有自己的依賴要求，並且如果有沖突的話，他們的作者會注意到的。要判定改動是屬於補丁級別還是次版級別，要看你更新依賴包是為了修復Bug，還是添加新功能。對於后者，我通常覺着會有額外的代碼，這種情況下，顯然是一個次版本號級別的遞增。
  • 如果我變更了公共 API 但無意中未遵循版本號的改動怎么辦呢？（意即在補丁級的發布中，誤將重大且不兼容的改變加到了代碼之中）
    自行做最佳的判斷。如果改回 API 預期的行為將強烈的影響你的大量受眾，那么可能最好再發一個主版本吧，即使這個修復僅僅被當做一個補丁版本。記住，Semantic Versioning 所做的就是，通過版本號的改動傳達含義。若這些改變對你的使用者很重要，那就通過版本號來告知他們。
  • 我該如何處理即將棄用的功能？
    棄用現存的功能，是軟件開發中正常的一部分，也通常是向前發展所必須的。當你棄用部份 API 時，你應該做兩件事：（1）更新你的文檔讓使用者知道這個改變（2）發布一個新的、仍然包含這些已經棄用的API 的次版本。在你從新的主版本里完全移除這些已棄用的功能之前，至少要有一個次版本 仍然包含這些已經棄用的 API，這樣使用者才能平滑地轉移到新版 API。
  • Semantic Versioning 對於版本的字串長度是否有限制呢？
    沒有，但自行判斷。舉例來說，一個包含255個字符的版本字符串很可能太過分了。並且，特定的系統對於字串長度可能會有他們自己的限制。

  1. "依賴地獄". 因為不好翻譯, 就不譯了. ↩

  2. "version lock" (如果不為每一個依賴包都發布一個新版本, 就沒辦法升級某個軟件包). ↩

  3. "version promiscuity" (承擔了與太多未來版本兼容的責任, 遠遠超過合理的需要). ↩

  4. 依賴過緊舉例: 假設軟件 A 依賴軟件 B, 聲明 A 的當前版需要 B 的 v1.1 版本, A 的下一個版本需要 B 的 v1.2 版本. 這就過緊了. 這樣如果要將A升級到下一個版本, 你就不得不同時發布 B 的 v1.2 版本; 依賴過松舉例: 聲明 A的當前版本需要B, 只要 B 的版本大於 v1.1 即可. 這樣子A 負擔過重了, 處理與太多的B的未來版本的兼容問題, 沒什么必要. ↩



作者：Shawn_xiaoyu
鏈接：https://www.jianshu.com/p/e2619a7aa60e
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯系作者獲得授權並注明出處。

 


免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。



猜您在找 uniapp實現app版本更新下載 uni-app 版本更新控制 Flutter實現APP版本更新 uni-app版本更新 uni-app版本更新（二） uni-app 實現APP的版本更新 uni-app 實現APP的版本更新 uni-app 實現APP的版本更新 iOS版本更新的App提交審核發布流程 iOS版本更新的App提交審核流程
 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM