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

前提

何爲版本？版本即語義版本控制（ 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 
複製代碼

or

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 是什麼以及自動更新的方法，那麼講一些更新的時候注意事項吧。

開始於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請多多指出，有功能上的問題也請直言不諱。

友情連接

藍色的秋風 無影er

參考

medium.com/fiverr-engi…

www.sitepoint.com/semantic-ve…

更多請關注