语义化版本规范
1. 概念
語義化版本規(guī)范(SemVer Semantic Versioning)是 GitHub 起草的一個具有指導意義的、統(tǒng)一的版本號表示規(guī)范。它規(guī)定了版本號的表示、增加和比較方式,以及不同版本號代表的含義。
在這套規(guī)范下,版本號及其更新方式包含了相鄰版本間的底層代碼和修改內容的信息。語義化版本格式為:主版本號.次版本號.修訂號(X.Y.Z),其中 X、Y 和 Z 為非負的整數(shù),且禁止在數(shù)字前方補零。
2. 規(guī)則
版本號可按以下規(guī)則遞增:
- 主版本號(
MAJOR):當做了不兼容的API修改。 - 次版本號(
MINOR):當做了向下兼容的功能性新增及修改。這里有個不成文的約定需要你注意,偶數(shù)為穩(wěn)定版本,奇數(shù)為開發(fā)版本。 - 修訂號(
PATCH):當做了向下兼容的問題修正。
你可能還看過這么一種版本號:v1.2.3-alpha。這其實是把先行版本號(Pre-release)和版本編譯元數(shù)據(jù),作為延伸加到了主版本號.次版本號.修訂號的后面,格式為 X.Y.Z[-先行版本號][+版本編譯元數(shù)據(jù)],如下圖所示:
我們來分別看下先行版本號和版本編譯元數(shù)據(jù)是什么意思。
先行版本號意味著,該版本不穩(wěn)定,可能存在兼容性問題,格式為:X.Y.Z-[一連串以句點分隔的標識符] ,比如下面這幾個例子:
1.0.0-alpha
1.0.0-alpha.1
1.0.0-0.3.7
1.0.0-x.7.z.92
編譯版本號,一般是編譯器在編譯過程中自動生成的,我們只定義其格式,并不進行人為控制。下面是一些編譯版本號的示例:
1.0.0-alpha+001
1.0.0+20130313144700
1.0.0-beta+exp.sha.5114f85
注意,先行版本號和編譯版本號只能是字母、數(shù)字,且不可以有空格。
3. 規(guī)范
- 標記版本號的軟件發(fā)行后,禁止改變該版本軟件的內容,任何修改都必須以新版本發(fā)行。
- 主版本號為零(
0.y.z)的軟件處于開發(fā)初始階段,一切都可能隨時被改變,這樣的公共API不應該被視為穩(wěn)定版。1.0.0的版本號被界定為第一個穩(wěn)定版本,之后的所有版本號更新都基于該版本進行修改。 - 修訂號
Z(x.y.Z | x > 0)必須在只做了向下兼容的修正時才遞增,這里的修正其實就是Bug修復。 - 次版本號
Y(x.Y.z | x > 0)必須在有向下兼容的新功能出現(xiàn)時遞增,在任何公共API的功能被標記為棄用時也必須遞增,當有改進時也可以遞增。其中可以包括修訂級別的改變。每當次版本號遞增時,修訂號必須歸零。 - 主版本號
X(X.y.z | X > 0)必須在有任何不兼容的修改被加入公共API時遞增。其中可以包括次版本號及修訂級別的改變。每當主版本號遞增時,次版本號和修訂號必須歸零。
4. 如何確定版本號
- 在實際開發(fā)的時候,建議你使用
0.1.0作為第一個開發(fā)版本號,并在后續(xù)的每次發(fā)行時遞增次版本號。 - 當我們的版本是一個穩(wěn)定的版本,并且第一次對外發(fā)布時,版本號可以定為
1.0.0。 - 當我們嚴格按照
Angular commit message規(guī)范提交代碼時,版本號可以這么來確定:
fix類型的commit可以將修訂號 +1。feat類型的commit可以將次版本號 +1。- 帶有
BREAKING CHANGE的commit可以將主版本號 +1。
語義版本規(guī)范完全說明
總結
- 上一篇: 2022-2028年中国绝热隔音材料行业
- 下一篇: 2022-2028年中国节能建材行业深度