語義版本控制:它是什麼,不是什麼,以及為什麼需要它

已發表: 2019-05-20

您使用的大多數軟件經常發布新版本,通常由相關的版本號標識。 該系統稱為“語義版本控制”,它使您能夠跟踪開發進度。 更重要的是,如果您使用 WordPress,您絕對可以從良好的語義版本控制實踐中受益。

在本文中,我們將向您簡要介紹語義版本控制系統及其工作原理。 然後我們將討論誰可以從使用它中受益,並為您提供一些技巧以確保您正確地使用它。

讓我們談談數字!

什麼是語義版本控制

如果您訪問 WordPress.org 的下載頁面,您會注意到它會告訴您正在下載的內容管理系統 (CMS) 版本:

WordPress 下載頁面。

用於確定此數字的系統稱為“版本控制”。 更具體地說,您正在查看語義版本控制的示例,其中發布被分解為由句點分隔的三個數字。 讓我們回顧一下這些值分別代表什麼:

  • 主要發布版本,與 API 的更改相關。
  • 軟件的小更新,不足以保證進行重大更新。
  • 補丁或錯誤修復。

在撰寫本文時,我們使用的是 WordPress 5.1.1 版。 5.0.0 版本於 2018 年 12 月 6 日發布。 從那時起,我們有五個小補丁(以最終數字為增量)和一個小版本,順序如下:

  1. 5.0.1
  2. 5.0.2
  3. 5.0.3
  4. 5.0.4
  5. 5.1
  6. 5.1.1

如您所見,每次有小更新時補丁號都會重置。 這同樣適用於主要版本的發布,對於 WordPress 而言,通常每四個月發布一次。

語義版本控制背後的重點是讓您跟踪所做的所有更改和進度。 更重要的是,如果您是最終用戶並且您跟上版本,版本號會告訴您何時真正需要更新。 例如,您可能會跳過一兩個錯誤補丁,但每次有次要或主要版本時,您都應該更新(我們正在關注,您知道!)。

如果您不確定更新是否值得,只需查看每個版本附帶的更改日誌即可。 每個稱職的開發人員都會對每個版本的新內容進行書面記錄。

總的來說,語義版本控制非常簡單,在軟件開發之外的許多情況下都很方便。 讓我們來談談那些是什麼。

誰可以從使用語義版本控制中受益

通常,您會發現使用版本控制系統的是開發人員。 至於 WordPress,最明顯的例子是核心本身的更新。 然而,插件和主題開發人員也使用語義版本控制,儘管這些數字通常很難找到。 例如,如果您查看 WordPress.org 上的插件頁面,您可以在“開發”選項卡中找到有關其版本和更改日誌的信息:

更改日誌的示例。

同樣,您可以在相關的 WordPress.org 頁面中找到有關主題開發的信息。 但是,在這些情況下,您必須單擊頁面底部的開發日誌鏈接:

開發日誌列表。

簡而言之,您幾乎可以將語義版本控制用於涉及代碼的任何類型的項目。 但是,它也有直接開發之外的應用程序。 例如,您可以將版本控制應用於設計項目。 在這裡,您可能希望增加主要視覺變化的版本號、新元素添加的值或小調整。 就補丁而言,您可以保留那些用於微小的視覺更新或更正。

然而,語義版本控制可能是鎮上最流行的遊戲,但它不是您可以使用的唯一系統。 例如,Chrome 瀏覽器採用四段式版本系統——major.minor.build.patch

其他項目,例如 Ubuntu,使用圍繞日期構建的系統。 例如,Ubuntu 目前的版本為 19.04,您可能已經猜到,該版本於 2019 年 4 月發布。

總的來說,沒有一個版本控制系統可以完美地適用於所有類型的項目。 但是,如果您從事任何類型的軟件開發,語義版本控制是一個很好的選擇。 另外,如果您還沒有使用任何類型的版本控制協議,這是一個很好的介紹。

語義版本控制的 3 個最佳實踐

到目前為止,您已經了解語義版本控制的工作原理。 但是,讓我們回顧一些提示,以確保您以正確的方式使用它。

1. 不要馬上開始使用 1.0 版

在某些時候,您可能使用過尚未達到 1.0 版的軟件。 這是完全正常的,因為用戶希望 1.0.0 版本相對穩定且沒有錯誤。 但是,這也會導致軟件需要很長時間才能達到該數字,同時仍然完全可用的情況。

以流行的 PC 遊戲《矮人堡壘》為例。 它已經開發了大約 15 年,儘管包含比大多數主要遊戲更多的功能,但仍在 0.44.12 版本上。

矮人要塞遊戲。

雖然您可能會對此採取極端措施,但不要立即從 1.0.0 版開始確實有意義。 它使您能夠對您的軟件進行 Beta 測試並在這樣做的同時降低用戶的期望。

在內部,您應該從 0.1.0 版開始。 然而,大多數項目不會公開這個版本,而是等到他們有更多的開發。 不過,與此同時,您可以使用那些非常有限的 alpha 版本進行內部測試,這是任何項目健康發展的關鍵。

2.解釋每個新版本的具體變化

作為最終用戶,您會發現自己最煩人的情況之一是在不知道其中任何一個做什麼的情況下獲得大量更新。 我們知道大多數人不閱讀變更日誌,但是如果您要發布更新——即使只是一個小補丁——您需要記錄下來。

更改日誌的示例。

顧名思義,變更日誌是每個版本的新內容的簡單細分。 一些開發人員編寫了冗長的更新來解釋每一個更改,如果您是其中之一,您將獲得更多權力。

老實說,我們通常只滿足於一個簡單的新內容列表。 整理變更日誌很簡單,應該不會花很長時間,所以要冷靜,不要吝嗇你的職責!

3. 收集每個版本的用戶反饋

您可能非常清楚您希望完成的項目是什麼樣子。 但是,這並不意味著您可以放棄來自用戶或團隊其他成員的反饋。

理想情況下,您會為您發布的每個版本獲得一定程度的反饋,除非是小補丁和錯誤修復。 此過程的目標是讓您知道用戶是否遇到任何問題,或者是否對項目前進的方向有問題。

此過程的最簡單示例是與客戶共享正在進行的網站的最新版本。 在絕大多數情況下,客戶會為您提供一定程度的反饋,您可以將其合併到未來的版本中。

但請記住——傾聽反饋很重要,但在某些情況下,您可能比用戶更了解。 然而,這並不意味著您應該忽略它們,但有時您的直覺可能是正確的。

結論

語義版本控制是一個非常簡單的系統。 只需幾個數字,您就可以傳達有關項目開發進度的大量信息,讓用戶知道何時有新的重要更新,並通常使事情井井有條。

讓我們回顧一下語義版本控制需要牢記的三個最佳實踐:

  1. 不要從門外的第一個版本開始。
  2. 解釋每個新版本的具體變化。
  3. 收集每個版本的用戶反饋。

您對如何使用語義版本控制有任何疑問嗎? 在下面的評論部分提問!

文章縮略圖來自 fatmawati achmad zaenuri / shutterstock.com