版本規範

在專案中版本建立是依照

建立，其原因是與用法可以參考 - Git Flow 是什麼?為什麼需要這種東西? - Using git-flow to automate your git branching workflow - git-flow 備忘清單

基本會以上述連結的內容經過整理後與分支規範結合運用，但其中有詳細運作方式會在下面詳細提出，如果認為有更好的方式可以在「議題」(Issues)提出想法。

語意化版本

軟體版本週期

「軟體版本週期」(SRLC, Software release life cycle)原指軟體開發後發佈前軟體測試的狀況，在此指團隊與社群開發的階段，分支名稱上「可」(SHOULD)出現，因為「軟體版本週期」(Software release life cycle)會使用「標籤」(Tag)做區隔，依照發佈的狀態分成: - 「準預覽版本」(Pre-alpha) - 「預覽版本」(Alpha) - 「測試版本」(Beta) - 「最終測試版本」(Released candidate) - 「完成版」(Gold)

準預覽版本

「準預覽版本」(Pre-alpha)就是指從develop分支出新的release時就是「準預覽版本」(Pre-alpha)，此時會依照分支規範與語意化版本命名成release/vX.X.X-Summary，同時加上「標籤」(Tag)vX.X.X-Pre-alpha，讓發佈狀態可以從「標籤」(Tag)與首頁快速得知目前開發的狀況。

此時會是核心團隊負責在GitLab針對「準預覽版本」(Pre-alpha)發佈的內容進行線上的內容審查，如果內容有問題也會要求社群在develop針對此發佈的內容修正。修正後使用git cherry-pick去選擇修正的版本內容，完成後會依照社群規範去決定是否通過，通過後會往下一個階段「預覽版本」(Alpha)。

預覽版本

那也就是說以攀樹手冊為例: - 當某項技術、課程與教學方式等新增 - 議題裡面討論覺得可以後關閉議題，且針對某項議題內的討論與連結的分支趨於完整 - 最低的限度就是先以章節為單位，針對以文字敘述上去分析安全性、完整性、正確性與可行性作為最低限度，只是前期可能會以可行性為主，畢竟是將我們所知道以及正在做的放上去 - Pull Requests到develop - 通過CI的風格化、圖片完整、超連結等基本檢查(理想與未來)與人工審查 - 刪除分支與關閉議題 - 關閉後針對可以開啟 release 分支讓社群再次驗證安全性、完整性、正確性與可行性 - 此時會以實際測試技術、課程與教學作為通過條件，只是前期可能會以可行性為主，畢竟是將我們所知道以及正在做的放上去 - 將進展的狀況打上Tag，類似要發佈的軟體有「軟體發佈生命週期」 - Pull Requests到master 1- 通過CI的風格化、圖片完整、超連結等基本檢查(理想與未來)與人工審查 1- 刪除分支與關閉議題順便打上Tag

所以進到develop比較容易，但進到master比較困難，類似法院的三讀通過，那實際測試的標準是什麼還要再寫