文件版本控制範本
文件版本控制範本：草稿如何以小數版本（0.1、0.2……）逐步經審閱推進，只在正式審批後才取得整數版本，其後的修訂又如何取代它所替換的版本。
甚麼是文件版本控制流程
版本號是一種簡寫，讓所有人一看就知道自己手上是文件的哪一份副本，以及它是否可以信賴。本範本遵循多數品質與文件管制系統採用的慣例：小數，例如 0.1、0.2、0.3，標示仍在內部審閱中的草稿；整數，例如 1.0、2.0、3.0，則標示已經真正獲批並發放的版本。這條規則說起來簡單，實際執行卻很容易破功——因為沒有甚麼能阻止有人純粹出於習慣，把一份草稿叫成下一個整數版本，而這正是編號機制存在的原因，用來防止這種混淆。
這張圖並非文件管制的完整生命周期。申請、起草、正式審批、發布與定期檢討——一份文件由頭到尾要走的整套程序——是 /yue/templates/文件管制流程 那張文件管制流程圖，本範本假定那套程序已經存在於它周圍。這張圖抽取的，只是那個生命周期裡的一個機制：版本號本身如何推進，而它刻意畫得比修訂記錄冊還要窄。記錄誰在何時改了哪一行，屬於一份平面的變更登記冊；這張圖只關心一份文件在生命歷程的每一個時點，有資格帶哪個編號。
編號不會在首次發布後就停止。一份已發布的文件如需再作變更，會以下一個版本重新走一次同樣的審閱與審批周期，而不是另開一份新文件；它所取代的那個版本會被標示為作廢，而不是刪除，好讓日後任何人打開一份舊的存檔或印本副本時，都能一眼看出它已經不是現行版本。
本流程圖涵蓋的內容
本範本包含
- 五條泳道，對應接觸版本號的每一個人：編寫人、審閱人、版本管理員、審批人與讀者，橫跨五個階段：草擬、內部審閱、修訂、審批，以及已發布並生效。
- 草稿編號：新文件在第一次派發之前，就已獲編配草稿版本 0.1，令任何人見到的第一份副本，已經帶着一個可追溯的編號。
- 審閱與遞增循環：「是否需要修改？」這道判斷，會令草稿先後經過「遞增小數版本」與「按意見修改草稿」，然後再送回重新審閱，於是 0.1 變成 0.2、0.2 變成 0.3，編號本身就記錄着草稿經歷過多少個循環。
- 整數版本關卡：「是否批准發放？」是這張圖裡唯一會導致獲派整數編號的判斷。被拒絕的草稿會循環返回小數版本的周期，而不會照樣獲得發放。
- 發布與取代：版本歷史登記冊會先更新，已批准的版本會發布到受控位置，它所取代的版本亦會標示為作廢——這一切都在讀者打開新副本之前完成。
- 發布後的循環：「發布後是否有變更要求？」這道判斷，會令一份生效中的文件以下一個版本，回到同一套審閱與審批周期，而不是把生效中的文件當成不可更改。
何時使用本範本
- 你們正在設計或編寫一套版本編號機制，需要具體展示——而不只是講述——草稿修訂與已發放版本之間的分別。
- 審閱人不斷把一份未發放的草稿當成已批准的版本來引用，例如把第三次審閱循環當成正式發放，只因為兩者在途中都被叫做「第 3 版」。
- 你們要決定整數版本的分界應該設在哪裡——正式審批、內容大幅重寫，還是固定的發布日程——並想要一個具體例子，先拿來討論，然後才定下規則。
- 你們需要向審核員或新上任的文件管理員解釋，為何一個已作廢的版本仍然可以在登記冊裡找到，而不是直接被刪除。
- 你們正在文件管理系統或範本庫裡設定版本編號規則，希望在動手建置之前，先把這個機制的運作方式畫出來。
運作方式
定下你們的小數與整數慣例
決定並寫低：草稿版本用小數，已發放版本用整數，又或者如果你們有另一套慣例，就採用那一套。具體方案是甚麼其實不太重要，重要的是它只需訂明一次，並且在版本號出現的每一處——包括頁首、頁尾與登記冊——都一致採用。
決定甚麼才算一次新的審閱循環
定下「遞增小數版本」背後的規則：是每一次標記意見都令編號上升，還是只有在完成修改、重新發出草稿時才上升？每一串留言都遞增一次的團隊，最終會見到二十幾版的草稿；只在重新發出時才遞增的團隊，編號才能保持有意義。
定下甚麼情況才配得上整數版本
正式審批是這張圖在「訂定整數版本 1.0」所用的觸發條件，但有些機構亦會在內容大幅重寫時調升整數編號，即使未經完整的重新審批。選定一條規則並貫徹採用，因為規則混用正是令版本號變得毫無意義的原因。
定義一個版本被取代之後會怎樣
在「把上一版本標示為作廢」這一步，決定那個舊版本此後存放在哪裡：連同作廢日期一併存檔在登記冊裡，還是從受控位置移除、但保留一段固定期限。兩種做法都站得住腳；沒有寫明答案才是問題。
決定發布後的變更如何編號
在「以下一個版本重新開啟文件」這一步，固定一條規則：生效中的文件一旦有變更，是在下一個整數的基礎上重新展開小數的草擬周期，還是接續上一個整數繼續用小數。這正是大部分團隊直到第二次修訂已經在進行中，才想起還沒寫低的規則。
常見問題
小數版本與整數版本有甚麼分別？
小數版本，即寫成 0.1 或 0.2 這樣的小數，標示一份仍在內部審閱、尚未獲批使用的草稿。整數版本，即寫成 1.0 或 2.0 這樣的整數，標示一個已經由審批人真正簽署、並已發布到受控位置的版本。這個分別存在的原因，是要令「第 2 版」這種說法，永遠指向一份已發放的文件，而不是一份剛好走到第二次審閱循環的草稿。
是不是每一輪審閱意見都會產生一個新的版本號？
這是由你們機構自行訂定的規則，而不是編號機制本身決定的事。許多團隊只在草稿重新發出、再進入一輪審閱時才遞增小數版本，而不是每一條個別意見都遞增，這樣編號才能保持為草擬循環次數的有意義計數，而不是編輯次數的計數。
一個版本被取代之後會怎樣，會被刪除嗎？
不會。一個被取代的版本會在版本歷史登記冊裡標示為作廢，並通常保留一段訂明的保存期限，因為它就是某個特定日期曾經生效的紀錄。它會從受控位置撤出，以免有人誤用，但直接刪除會抹走日後審核員或事故調查可能需要的證據。
這與文件管制流程或修訂記錄冊有甚麼分別？
/yue/templates/文件管制流程 那張文件管制流程圖，是一份文件所走的完整生命周期：申請、起草、審閱、審批、簽發、分發與定期檢討，本範本假定那套生命周期已經存在。修訂記錄冊則是一份平面的登記冊，記錄個別變更——誰在何時改了甚麼。這張圖介乎兩者之間：它只是那個機制，決定一份文件在生命周期的每一個時點，有資格帶哪一個編號，小數還是整數。
此流程所處的位置
在大多數機構中，此流程緊接文件管制流程圖之後，並交接給文件審批工作流程決策樹。
它是文件管制中的其中一個步驟。
第 1 步: 文件管制流程圖
文件管制流程圖，設有撰寫人、審閱人、審批人、文件管理員與最終用戶五條泳道：起草、審批、發放與定期檢討。
第 2 步: 文件版本控制範本 當前位置
文件版本控制範本：草稿如何以小數版本（0.1、0.2……）逐步經審閱推進，只在正式審批後才取得整數版本，其後的修訂又如何取代它所替換的版本。
第 3 步: 文件審批工作流程決策樹
文件審批工作流程的決策樹：編輯性修改還是實質性修改、按文件類別而定的必審審閱人、第二審批人，以及發布時的已閱並理解要求。
第 4 步: 文件變更控制流程圖
第 5 步: 政策檢討審批流程圖（由觸發到閱讀確認）
