內部團隊軟體專案協同開發基本規則:

一、開發期間所釋放(release)的版本一律為 1.0 以內。亦即,如 CEDT_WK_0.9 版。

二、在開發期間,針對每一次的 “MileStone”,也就是完成比較重要的功能後,則其版本在同一個小數點往前推進(如 0.6->0.7)。注意的是,必須是以標記(TAG)來手動制訂。

三、正式版本的推出,則以 1.0 開始。如 CEDT_WK_1.0 版。
  小幅度功能的增加或修正一些 Bugs,則以 1.1->1.2->1.3 ... 漸增。

四、大幅度的功能提升或修正,則推進至 2.0 版。

附錄:基本說明:(主要內容參考 臥龍小三 CVS 入門說明)

1.  Version(版本)、Revision(修訂版)、Release(發行版):
    Revision:開發期間的版本稱為 Revision(校訂版)。
    Release:釋放給客戶使用的版本稱為 Release(發行版)。

CVS 的版次編號(revision number)只做為 CVS 內部控管之用,和將來發行的軟體版本(version)
無關。
也就是說:若某一支程式在 CVS 中版次編號為 1.5,而發行的軟體版本 “您把它稱為” SFS 3.0 版,那麼,這個 1.5 內部版次和 3.0 軟體版本,是完全風馬牛不相關的!
CVS 的版次成長的過程如下:
第一次將專案匯入 CVS Server 時,所有檔案的版次編號皆為 1.1.1.1。若修改存入檔案庫之後,版次編號就由 1.2 起跳,爾後每存入一次,版次編號就增加 1。您可以放心儘情地修改,不同的程式檔之間的版次編號不必一致,也就是說:一個專案中,A 這支程式到了 1.83 版,B 這支程式只到了 1.3 版,並不會影響將來發行軟體的版本,我們可以利用標記(tag)等方式,來達到進一步控管的功能。

2. 取出過去的專案版本:

CVS 提供二種方式取出過去的專案版本:
1). 依時間點取出 (by date)
2). 依標記取出 (by tag)

專案會一直往前發展,終於有一天,領導人評估之後,認為該專案目前已經穩定成熟,可以推出正式版本了。這時,領導人通常會給專案的程式碼加上一個標記,比如:r2002_10_20,然後將專案打包,並為該軟體命名一個發行版本(如 SFS 3.0 版)。
不過,正式版推出一段時間之後,可能會有使用者發現軟體在某些地方功能不太正常,因此將問題回報給專案成員。而這段期間,專案仍持續不斷地往前發展,在發展中的這種最新版本,通常不穩定,無法立即可用,實在不適合正式推出。為了修正程式碼中的臭虫,有必要取出過去的程式碼。此時,當初設定的標記就十分重要了 ! 我們可以根據標記,取出當時專案中的所有程式碼,以進行修正的動作。至於目前持續發展中的版本,則不會受到任何影響。
當然,也可以依時間點來取出當時的專案,不過,正式版究竟在何時推出的? 可能很難追憶,所以,一般而言,還是以使用標記的方式居多。

*** 請記住一個觀念:當您取出過去的專案時,目前的工作版本會暫時變成舊專案,若修改它,您是無法把它存入 CVS 檔案庫中! 因為它是過去的歷史,CVS 不容許您修改歷史,此時必須在原先的發展路線上,開闢另外一個分支(branch),所有修正臭虫的程式碼,全部在這條分支上去進行。

3. 分支(branch):

CVS 可以讓您回到某一穩定版本,由該處去修正程式的錯誤,修正的結果循另一條路線發展,以提供更可靠的程式版本。這就是分支的概念。原來的主要發展版本,我們就稱之為主幹(HEAD)。

4. 合併分支及主幹:

分支的目的之一是為了修正某些程式的錯誤,開發中的版本,極可能也有這個 bug 存在,因此通常分支修改完之後,會和主幹做合併的動作。
假設 r2002_10_20 推出正式版之後,發現有 bug,為了修正臭虫,於是做了分支
r2002_10_20_branch。以 index.php 為例,設若 bug 是在 index.php 中,且已被修正,今想把它和主幹合併,以修正主幹的錯誤。

5. 取出專案,推出(release)軟體版本:
當我們 checkout 出庫存專案時,在工作目錄下每一個子目錄中皆有一個 CVS 資訊目錄,但我們要推出正式版本的軟體,不希望把這些 CVS 目錄也打包進去。CVS 有提供一個動作命令,用來取出不含控制訊息的整份專案。