前提
何為版本?版本即語義版本控制( Semantic version 後面簡稱為 SemVer )是一種版本控制系統,在過去幾年中一直在不斷髮展。 隨著每天都在構建新的外掛,外掛,擴充套件和庫,擁有通用的軟體開發專案版本化方法是一件好事,可以幫助我們跟蹤正在發生的事情。
SemVer 的格式式為 x.y.z,其中:
x代表主要版本( Major )
y代表次要版本( Minor )
z代表補丁( Patch )
SemVer如何工作?
通過 SemVer 來確定你應該釋出的版本型別是很簡單的。
如果你修復 bug 或者一些細節修改,那麼這將被歸類為補丁,在這種情況下你應該升級z。
如果你以向後相容的方式實現新功能,那麼你將升級y,因為這就是所謂的次要版本。
另一方面,如果你實現了可能破壞現有API的新東西,你需要升級x,因為它是一個主要版本( Major )。想要了解更多請看後面的<更多須知>。
開始
語義化的版本控制對應用來說是非常重要的,當然,讓版本升級就變成了一件看似不重要卻非常重要的事情,在我們開發過程中,或者你遇到過這樣的情況?
- 由於版本控制概念模糊或者忘記,build 完應用都是隨便改的版本或者是完全忘記修改版本。
- 每次 build 完需要改版本太麻煩,懶得改。
基於這樣的場景下,我開發了這款自動版本升級管理工具 auto-vers
github: https://github.com/zerolty/au…
相同庫比較
專案 | npm-auto-version | update-version | auto-vers |
---|---|---|---|
git tag | 支援 | 不支援 | 支援 |
自動更新 | 不支援 | 支援 | 支援 |
提示更新 | 不支援 | 不支援 | 支援 |
手動與auto-vers比較
下面是我們需要手動改(前提需要知道改成什麼,並且不能忘記修改!)
下面是使用了auto-vers的方式。
擁有的功能
- [x] 更新 major, minor, patch, premajor, preminor, prepatch or prerelease
- [x] 在更新時候提示選擇
- [x] 支援git tag方式
- [ ] 根據git commit的資訊來自動推薦合適的版本
使用
Node 和 Cli兩種引入方式。
npm i auto-vers -g
Cli
基礎模式
cat package.json
{
...
"version": "1.0.0"
...
}
auto-vers -i
cat package.json
{
...
"version": "1.0.1"
...
}
確認模式
auto-vers -i -c
提示模式
auto-vers -t
如果你不想更新 , 你可以使用 ctrl
+ c
去停止。
提示和Git組合模式
使用這個選項後,在你選擇一個版本後,會自動幫你提交一個commit,並且打上一個tag。
auto-vers -t -g
直接更改模式
auto-vers 1.2.0
or
auto-vers -v 1.2.0
options
auto-vers 1.0.2
Auto update version for your application
Usage: auto-vers [options] <version> [[...]]
Options
-v --version <version>
Can update version directly.
-i --inc --increment [<level>]
Increment a version by the specified level. Level can
be one of: major, minor, patch, premajor, preminor
, prepatch or prerelease. Default level is `patch`.
Only one version may be specified.
-e --extra [<value>]
This is for prerelease extra data
Such as `beta`,`alpha`
-c --confirm
Do not update the version directly, you can confirm.
This is a safe mode.
-t --tip
Provide choice to you. If you don`t know how to update
you can choose this option.
-g --git
Help you make a tag.(Make you have a git repo)
最佳實踐
在你打包完你的專案同時執行這個命令是一個非常好的選擇。
基礎的方式
"script": {
"build": "babel ./src --out-dir ./dist",
"tip": "npm run build && auto-vers -t",
"version": "npm run build && auto-vers -t -g",
}
在你寫好一段打包命令後,緊接著跟上auto-vers -t
,將會給你提示需要升級至多少版本,這對你來說會有一定的指示意義。幫助你更好地區判斷你需要升級至什麼版本。auto-vers -t -g
這個命令適合於你單獨釋出一個版本,可以一鍵式的幫助你從修改 package.json -> git commit -> git tag -> git push origin [tagname] 整個流程。
中級的方式
"script": {
"build": "babel ./src --out-dir ./dist",
"patch": "npm run build && auto-vers -i -c",
"minor": "npm run build && auto-vers -i minor -c",
"major": "npm run build && auto-vers -i major -c",
"beta": "npm run build && auto-vers -i prerelease -c",
}
這個方式針對熟悉這個模式的人,每次需要打包只需要執行對應的命令。(增加引數-c --confirm
,這是一個安全的方式去升級,幫助你確認是否升級正確,如果對你而言是一個繁瑣的步驟即可去掉。)
高階的方式
git-hooks
如果你沒有註冊pre-commit
和post-commit
,可以直接移動進你的.git/hooks目錄下
mv githook-*/* .git/hooks/
如果你本地存在hooks,將專案下的hook,手動新增到你的hook下
cat githook-*/pre-commit >> .git/hooks/pre-commit
當你提交 commit 的時候,會自動跳出選擇介面,選擇後升級對應的版本。 (注意:如果在你的程式中有相關 commit 命令,請使用--no-verify
來跳過此鉤子,否則將迴圈呼叫)
更多須知
為什麼選擇SemVer
因為不規範的版本號基本上沒有任何意義。從
4.1.0
升級4.2
? 好的。 為什麼? 為什麼不是5
? 為什麼不是4.1.1
? 為什麼不是4.11
? 為什麼不是4.1.0-aplha.0
?嚴格的指導原則有助於為版本號提供意義。例如,如果您看到版本
1.3.37
,那麼您將知道這是第一個主要版本,但已經有3個次要版本帶來了新功能。 但是,您還會注意到這是此次要版本中的第37個補丁,這意味著涉及很多錯誤(很少或很大)。它還有助於管理依賴關係,
"babel-cli": "~6.26.0",
我們引入了babel-cli
, 可以得知他的版本是6.26.0
,他會鎖定x,y
這是一種比較保守的方式, 根據規則可以得知,z的升級不會導致我們api重大的改變以及引入新的功能,。但是如果babel-cli
不遵循 SemVer , 在升級z的時候引入了破壞性的變化,這會使得我們的應用出現bug或者變得不可用。正是因為有了 SemVer 的規範,使得我們能夠放心地鎖定 x,y, 讓 z 可以自動升級,因為 z 的升級可能會修復一些小 bug 或者一些細節的改進, 在不破壞我們的應用同時能夠對已知bug進行修復。
更多技巧
既然你已經知道 SemVer 是什麼以及自動更新的方法,那麼講一些更新的時候注意事項吧。
開始於0.1.0
使用SemVer時需要注意的一點是它從0.1.0
開始,而不是像我們想象的那樣從0.0.1
開始。這是有道理的,因為我們不是從補丁開始,而是從一組功能開始,作為專案的初稿,因此版本為0.1.0
。
在1.0.0之前只是開發階段
每當你構建一個新的軟體時,總會有一個迷茫階段,你一直在問自己:我什麼時候應該釋出第一個正式的主要版本?
以下是一些幫助你回答這個問題的提示:如果您的應用已經在生產中使用或者使用者依賴於它,那麼你應該已經達到了1.0.0
。此外,如果你有打破當前的API,這同樣表示你需要升級你的主版本號了。
否則,請記住1.0.0
以下的版本基 本上是開發熱潮時期,你專注於完成你的功能。在1.0.0
之前,你不應該害怕任何破壞性的功能,這樣當達到1.0.0
時,它就會穩定。
關於預釋出pre-realease
在部署主要版本之前,你通常會經歷大量需要一次又一次測試的工作,以確保一切正常。
使用SemVer,可以通過在版本中附加識別符號來定義預釋出。 例如,版本1.0.0
的預發行版可能是1.0.0-alpha.1
。 然後,如果需要另一個預版本,它將變為1.0.0-alpha.2
,依此類推。
總結
通過了上面的基礎介紹,如果你沒有使用 SemVer ,沒有理由不在你的下一個專案(或當前專案?)上使用它。 它不僅有助於你的專案版本變得有意義,而且還有助於其他可能將你的專案用作依賴項的人。說了這麼多,最終還是希望大家能夠更加規範地開發專案不僅幫助他人,而且有利於自己。可能我開發的這個專案不是那麼完美,但是初衷是來提高大家規範的效率。有bug請多多指出,有功能上的問題也請直言不諱。