This section applies only to packages using CVS at cvs.php.net.
Include the $Id$ CVS keyword in each file. As each file
is edited, add this tag if it's not yet present (or replace
existing forms such as "Last Modified:", etc.).
The rest of this section assumes that you have basic knowledge
about CVS tags and branches.
CVS tags are used to label which revisions of the files in your
package belong to a given release. Below is a list of the
required and suggested CVS tags:
(required) Used for tagging a release. If you don't use it,
there's no way to go back and retrieve your package from the
CVS server in the state it was in at the time of the release.
(branch, optional) If you feel you need to roll out a
release candidate before releasing, it's a good idea to make a
branch for it so you can isolate the release and apply only
those critical fixes before the actual release. Meanwhile,
normal development may continue on the main trunk.
(branch, optional) If you need to make
example 1.2.1 and so on after 1.2.0), you can use a branch for
that too, if your main trunk is very active and you want only
minor changes between your micro-releases.
Only the RELEASE tag is required, the rest are recommended for
Below is an example of how to tag the 1.2.0 release of the
$ cd pear/Money_Fast
$ cvs tag RELEASE_1_2_0
By doing this you make it possible for the PEAR web site to take
you through the rest of your release process.
Here's an example of how to create a QA branch:
$ cvs tag QA_2_0_0_BP
$ cvs rtag -b -r QA_2_0_0_BP QA_2_0_0
$ cvs update -r QA_2_0_0
$ cvs tag RELEASE_2_0_0RC1
...and then the actual release, from the same branch:
$ cvs tag RELEASE_2_0_0
tag is a
tag, which is the start
point of the tag. It's always a good idea to start a CVS branch
from such branch points. MAINT branches may use the RELEASE tag
as their branch point.