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

一、開發期間所釋放(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 有提供一個動作命令，用來取出不含控制訊息的整份專案。