pkg版本規範管理自動化最佳實踐

Git · 發表 2019-01-21 10:56:28

摘要：何為版本？版本即語義版本控制（ Semantic version 後面簡稱為 SemVer ）是一種版本控制系統，在過去幾年中一直在不斷髮展。隨著每天都在構建新的外掛，外掛，擴充套件和庫，擁有通用的軟體開發專案版本化方法是一件好事，可以幫助我們跟蹤正在發生的事情。 SemVer 的格式式...

何為版本？版本即語義版本控制（ 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: github.com/zerolty/aut…

相同庫比較

專案	npm-auto-version	update-version	auto-vers
git tag	支援	不支援	支援
自動更新	不支援	支援	支援
提示更新	不支援	不支援	支援

手動與auto-vers比較

下面是我們需要手動改（前提需要知道改成什麼，並且不能忘記修改！）

下面是使用了auto-vers的方式。

擁有的功能

更新 major, minor, patch, premajor, preminor, prepatch or prerelease
在更新時候提示選擇
支援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 
複製程式碼

auto-vers -v 1.2.0 
複製程式碼

options

auto-vers 1.0.0

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 ，沒有理由不在你的下一個專案（或當前專案？）上使用它。它不僅有助於你的專案版本變得有意義，而且還有助於其他可能將你的專案用作依賴項的人。說了這麼多，最終還是希望大家能夠更加規範地開發專案不僅幫助他人，而且有利於自己。可能我開發的這個專案不是那麼完美，但是初衷是來提高大家規範的效率。有bug請多多指出，有功能上的問題也請直言不諱。