版本命名及限定規則詳解

Zhuxy 發布于2019-06-28 13:51 / 519人閱讀

理解版本命名及限定規則

前言:講解版本命名和版本限定的相關知識

版本命名規則

我們常見的版本命名格式為

[name].x.y.z-[state]

name為可選字段,一般為 v,表示 version

x.y.z 為各版本的序號，遵循語義化版本命名規范
實際上基于此規范,不應該在版本前出現 name 字段.

state 可選字段,表示版本狀態,例如 b 表示 beta 測試版,其他常見狀態,后有詳述

語義化版本命名規則

該規則對版本的迭代命名,做了很好的限制.
核心規則如下.

序號	格式要求	說明
x	非負整數	主版本號(major)，進行不向下兼容的修改時，遞增主版本號
y	非負整數	次版本號(minor)，保持向下兼容,新增特性時，遞增次版本號
z	非負整數	修訂號(patch),保持向下兼容,修復問題但不影響特性時，遞增修訂號

0.y.z 表示開發階段，一切可能隨時改變，非穩定版。

1.0.0 界定此版本為初始穩定版，后面的一切更新都基于此版本進行修改。

版本狀態

描述方式	說明	含義
α或a	alpha 版	內測版本，內部測試的版本，bug 較多
β或b	beta 版	公測版本，給外部進行測試的版本，有缺陷
γ或g	Gamma 版	相當成熟的測試版，于發行版相差無幾
rc	Release Candidate	是前面三種測試版的進一步版本，實現了全部功能，清除了大部分 bug，接近發布倒計時，有時會進一步細分為 rc1,rc2

實際上大部分前端工具均遵守上述規則

在商業軟件中還會見到如下字段.

描述方式	說明	含義
Demo	演示版	只集成了正式版部分功能，無法升級
SP	SP1	是 service pack 的意思表示升級包
Trial	試用版	試用版
Unregistered	未注冊	有功能或時間限制的版本
Lite	精簡版	只含有正式版核心功能
enhance	增強版	屬于正式版1
free	免費版	自由使用版本
release	發行版	有時間限制
upgrade	升級版	有功能增強或修復 bug
Retail	零售版	多帶帶發售
Cardware	共享版	公用許可證

版本限定

在進行包管理時,為了保證安裝依賴的兼容性.
必須對依賴包版本進行限定.參考 npm 限定描述
舉例如下

{
  "devDependencies": {
    "karma": "0.13.22"
  }
}

表示安裝 0.13.22 版本的 karma.

為了方便理解,版本限定的語法簡述為為 [范圍描述]<版本號描述>

范圍描述可選,必須配和版本描述確定范圍,無法獨立存在

< 小于某一版本號

<= 小于等于某一版本號

> 大于某一版本號

>= 大于等于某一版本號

= 等于某一版本號,沒有意義和直接寫該版本號一樣

~ 基于版本號描述的最新補丁版本

^ 基于版本號描述的最新兼容版本

- 某個范圍,他應該出現在兩個版本描述中間,實際上語法應為 <版本描述>-<版本描述>,寫在此處為了統一

嚴格來講對 ~,^ 的表述需要結合具體的包管理工具和版本號規則來確定.但是對于一般使用記住如下原則.
^ 是確保版本兼容性時,默認對次版本號的限定約束
~ 是確保版本兼容性時,默認對補丁號的約束

利用 ^,~ 的意義在于確保工具包對依賴版本的兼容性,排除主版本更迭,
造成依賴失效的可能.

版本描述

* 通配符,類似 glob 模式 *

x,X 約等于 * 號,通常用于次版本和補丁的通配.

0.x 警惕這種版本,說明該依賴還未穩定(如果它遵守語義化命名的話),此外由于 0.x 版本隨時可能改變,此時 ^,~ 的都表示為對補丁版的限制.

相關舉例如下

< 1.2.3     小于1.2.3 的版本均可 
= 1.2.3     只支持等于1.2.3 的版本 
<= 1.2.3    只支持小于等于1.2.3 的版本
> 1.2.3     只支持大于 1.2.3 的版本
>= 1.2.3    只支持大于等于 1.2.3 的版本
1.2.3-2     支持 >=1.2.3 <3.0.0 的版本
1.x.1       支持 >=1.0.1 <1.1.0 的版本
*           支持 >= 0.0.0 的版本
""          同 *
1           表示 >=1.0.0 <2.0.0 其余任意位置為空相似
1.0         >= 1.0.0 < 1.1.0
~1.1.1      >=1.1.1 <1.2.0
~1.1        >=1.1.0 <1.2.0
~1          >=1.0.0 <2.0.0
^1.1.1      >=1.1.1 <2.0.0
^0.1.1      >=0.1.1 <0.2.0 注意這里,不要以為是 0.1.1-1.0.0 之間
^0.0.1      >=0.0.1 <0.0.2 同上,請注意

注意大部分包管理工具均遵守上述規則,但是在進行版本限定時,請參考包管理工具的配置項說明,確定語法格式.

總結

最常用的知識

核心命名規則

版本號通常稱為 x.y.z

x 主版本號,一般向下不兼容時增加此值

y 次版本號,向下兼容,添加新特性時增加此值

z 補丁號,修復問題為改變特性時增加此值

a,b,rc 分別表示內測,公測,發行狀態

版本限定

~ 在依賴版本兼容下,最近的補丁版

^ 在依賴版本兼容下,最近的次版本

重點是保證版本依賴的兼容性,不允許出現依賴的主版本號范圍可變,即使你的開發包依舊可用

參考資料

語義化版本規范

npm 版本說明

composer version constraints

百度文庫-版本說明詳解

wiki 軟件版本

What"s the difference between tilde(~) and caret(^) in package.json

GPU云服務器云服務器變量命名規則公司域名的命名規則二級域名命名規則服務器的命名規則

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/25912.html

正則表達式詳解

摘要：學習正則表達式也是如此，循序漸進，方能厚積薄發。概念分組捕獲是指將想要匹配的正則表達式用小括號括起來，然后與限定符組合使用，可以連續匹配符合規則的字符串。正則表達式是一個非常有用的用來匹配驗證字符串的工具。很多人覺得正則表達式規則繁多，學了也會忘記，不如等到需要使用的時候再去查閱即可。這樣的觀點也無可厚非，不過我曾經看到過一個絕妙的關于閱讀的比喻，閱讀就像是將竹簍浸入到水里面，雖然撈...

keelii 2019-08-23 13:51 評論0 收藏0
【轉】php命名空間

摘要：命名空間可以解決以下兩類問題用戶編寫的代碼與內部的類函數常量或第三方類函數常量之間的名字沖突。在命名空間內部訪問全局類函數和常量調用全局函數訪問全局常量實例化全局類命名空間和動態語言特征命名空間的實現受到其語言自身的動態特征的影響。 PHP 命名空間(namespace)是在PHP 5.3中加入的，如果你學過C#和Java，那命名空間就不算什么新事物。不過在PHP當中還是有著相當重要...

Jrain 2019-06-27 16:28 評論0 收藏0
Spring詳解3.Bean的裝配

摘要：的依賴關系，根據依賴關系配置完成之間的裝配。的行為信息，如生命周期范圍及生命周期各過程的回調函數。使用該種裝配模式時，優先匹配參數最多的構造函數。如果提供了默認的構造函數，則采用否則采用進行自動裝配。點擊進入我的博客 1 Spring容器與Bean配置信息 Bean配置信息 Bean配置信息是Bean的元數據信息，它由一下4個方面組成： Bean的實現類 Bean的屬性信息，如數...

endiat 2019-08-16 14:15 評論0 收藏0
Web前端開發規范文檔

摘要：前端開發規范文檔規范目的使開發流程更加規范化。中的非注釋類中文字符須轉換成編碼使用，以避免編碼錯誤時亂碼顯示。文件規范文件名用英文單詞，多個單詞用駝峰命名法。書寫規范命名規范。圖片規范命名應用小寫英文數字組合，便于團隊其他成員理解。 Web前端開發規范文檔規范目的：使開發流程更加規范化。通用規范： TAB鍵用兩個空格代替（WINDOWS下TAB鍵占四個空格，LINUX下TAB鍵...

付倫 2019-08-28 18:16 評論0 收藏0
Web前端開發規范文檔

摘要：前端開發規范文檔規范目的使開發流程更加規范化。中的非注釋類中文字符須轉換成編碼使用，以避免編碼錯誤時亂碼顯示。文件規范文件名用英文單詞，多個單詞用駝峰命名法。書寫規范命名規范。圖片規范命名應用小寫英文數字組合，便于團隊其他成員理解。 Web前端開發規范文檔規范目的：使開發流程更加規范化。通用規范： TAB鍵用兩個空格代替（WINDOWS下TAB鍵占四個空格，LINUX下TAB鍵...

Chiclaim 2019-08-21 10:39 評論0 收藏0