User: mnf999 Date: 01/06/15 15:24:03 Added: . CVSAdmin.jsp Log: Putting the JSP format online Revision Changes Path 1.1 newsite/CVSAdmin.jsp Index: CVSAdmin.jsp =================================================================== <jsp:include page="head.jsp" flush="true" /> <jsp:include page="slogan.jsp" flush="true" > <jsp:param name="SLOGAN" value="JBoss CVS Administration Policy"/> </jsp:include> <p class="head">INTRODUCTION This document describes the JBoss CVS administration policies for managing the sourceforge cvs repository. Comments or questions regarding these polcies should be directed to the <a href="mailto:[EMAIL PROTECTED]";>jboss-development mailing list</a> <p class="head">CREATING AND MANAGING RELEASE BRANCHES The CVS branching and release management proceedures are outlined in this section. All development of new features occurs on the main trunk. Releases are done on branches off of the main trunk. <p class="head">Release Numbering Releases are tracked using CVS tags that have the following forms: <ul> <li>Final Binary Releases: JBoss_<major>.<even_minor>.<patch></li> <li>Beta Binary Releases: Rel_<major>.<even_minor>.<patch>.<build></li> <li>Development Binary Releases(optional): JBoss_<major>.<odd_minor>.<patch></li> <li>Alpha Development Builds(optional): Rel_<major>.<odd_minor>.<patch>.<build></li> </ul> <p class="text">A final binary release is a tested and approved release of the JBoss server. The major and minor version numbers are fixed for a given branch. The minor version number is always even on a release branch. Example final release tags are: JBoss_2_2_0, JBoss_2_2_1, JBoss_2_4_13, JBoss_3_0_0 <p class="text"> A beta binary release is a candidate final release that is being made available for testing. The major and minor version numbers are fixed for a given branch. The patch number is one greater than the current final binary. The build number indicates the number of patches that have been incorporated into the candidate release. For example, if the latest final release is JBoss_2_2_0, then next beta binary release patch number will be 1 and build numbers will start at 1. A build number of 0 is used to tag the previous final release code. So, if JBoss_2_2_0 were the latest final release, and three fixes were incorported into the 2.2 branch, there would be beta binary release tags of Rel_2_2_1_0, Rel_2_2_1_1 Rel_2_2_1_2, Rel_2_2_1_3. The idea is that beta binary releases are building to the next final binary release, in this case JBoss_2_2_1. <p class="text">A development binary release is an alpha release of the JBoss server. It is a snapshot of the functionallity in the main trunk at some point in time. The major version number is >= the latest final binary release. The minor version number is 1 greater than the latest final binary release minor version number. This means that minor versions of development binaries will always be odd. Example development binary releases are: JBoss_2_3_0, JBoss_2_3_1, JBoss_2_5_13, JBoss_3_1_0 <p class="text"> A alpha development build is a patch beyond a development binary release. The patch number is one greater than the current development binary. The build number indicates the number of patches that have been incorporated into the candidate build. For example, if the latest development build is JBoss_2_3_0, then next alpha build patch number will be 1 and build numbers will start at 1. A build number of 0 is used to tag the previous devlopment build code. So, if JBoss_2_3_0 were the latest development build, and three fixes were incorported into the main trunk, there would be alpha release tags of Rel_2_3_1_0, Rel_2_3_1_1 Rel_2_3_1_2, Rel_2_3_1_3. The idea is that alpha builds are leading to the next development build, in this case JBoss_2_3_1. <p class="head">EXAMPLE RELEASE SCENARIOS Consider events 1-12 in blue on the following figure: <img src="pictures/cvs_structure.png" width="700" height="550" border="0" title="CVS Branch Structure" alt="CVS Structure"> <ol start="0"> <li> Prior to event 1, the latest alpha development build is Rel_2_1_0_57. At this point it is decided to create a new binary release. <li> Event 1 is the creation of a 2.2 branch. It is labeled with a branch tag of Branch_2_2. This fixes the major version to 2 and the minor version to 2 for all tags on this branch. <li> Event 2 is the creation of a Rel_2_2_0_0 beta release tag in the branch. It serves as an alias to the state of the main branch at the time the 2.2 branch was created. <li> Event 3 is the creation of a Rel_2_3_0_0 alpha release tag on the main trunk. It it is also an alias to the state of the main branch at the time of the 2.2 branch creation. <li> Event 4 is the integration of the first patch/change into the 2.2 branch. After the code is commited the Rel_2_2_0_1 tag is applied. <li> Event 5 is the release of the initial 2.2 branch binary. The release is tagged as JBoss_2_2_0 as well as Rel_2_2_1_0 to start the next beta series. <li> Event 6 is the integration of the first patch/change after the 2.2.0 binary release. After the code is commited the Rel_2_2_1_1 tag is applied. <li> Event 7 is the release of the second 2.2 branch binary. The release is tagged as JBoss_2_2_1 as well as Rel_2_2_2_0 to start the next beta series. <li> Event 8 is the creation of a new binary release branch. After some period of development on the 2.3 releases(Rel_2_3_0_0 to Rel_2_3_1_37), it is decided to release a final binary incorporating the main trunk functionality. The new 2.4 branch is labeled with a branch tag of Branch_2_4. This fixes the major version to 2 and the minor version to 4 for all tags on this branch. <li> Event 9 is the creation of a Rel_2_4_0_0 beta release tag in the branch. It serves as an alias to the state of the main branch at the time the 2.4 branch was created. <li> Event 10 is the creation of a Rel_2_5_0_0 alpha release tag on the main trunk. It it is also an alias to the state of the main branch at the time of the 2.4 branch creation. <li> Event 11 is the integration of the first patch/change into the 2.4 branch. After the code is commited the Rel_2_4_0_1 tag is applied. <li> Event 12 is the release of the initial 2.4 branch binary. The release is tagged as JBoss_2_4_0 as well as Rel_2_4_1_0 to start the next beta series. </ol> <p class="head">CVS TASK HOWTO <p class="head">CHECKING CODE INTO THE MAIN TRUNK New features and bug fixes on unreleased code should go into the main trunk which is the latest development branch. The steps for doing this are: <ol> <li>Checkout the target module in which the changes are to be made. For example to commit changes to the jboss module do: <pre>cvs co jboss</pre> <li>Make your chages to the source in the jboss working directory created by the previous check out. <li>Commit your changes. Do this by executing the following command in the directory you made the changes in, or any common parent directory: <pre>cvs commit -m "Your commit msg"</pre> You don't have to specify the commit msg on the commit command line. If you don't you will be prompted for the commit msg. Note that this will apply the same commit msg to all files you have changed. If you want specific commit msgs for each file then you can perform a seperate commit on each file. <li>(optional) Tag the code with the next alpha build tag. For example, to tag the jboss source tree with a Rel_2_3_1_3 tag, do: <pre>cvs tag Rel_2_3_1_3</pre> from within the jboss/src working directory. </ol> <p class="head">CREATING A NEW BINARY RELEASE BRANCH <ol> <li> Perform a clean check out of the jboss main branch without any tags to select the latest code: <pre> cvs co jboss </pre> <li> Create the new branch giving it a branch tag of Branch_<major>_<minor>. For example, to create a 2.2 branch, perform the following within the working directory created by the previous check out: <pre> cvs tag -b Branch_2_2 </pre> <li> Create a working directory for the new branch by checking it out using the Branch_2_2 tag: <pre> cvs co -r Branch_2_2 </pre> <li> Label the branch working directory with the initial beta release tag of Rel_<major>_<minor>_0_0. For the Branch_2_2 case this would be done by executing the following in the working directory created by the previous check out: <pre> cvs tag Rel_2_2_0_0 </pre> </ol> <p class="head">CHECKING IN A PATCH ON A RELEASE BRANCH When you have changes that need to go into the codebase of a release branch, you need to check out that branch and make the changes. So for example, if you need to add a patch the the 2.2 branch of the example cvs structure above, you need to first check out the 2.2 branch using the Branch_2_2 tag. <li>Checkout the module using the branch tag you want to work on. To checkout the 2.2 branch of the jboss module do: <pre>cvs co -r Branch_2_2 jboss</pre> This will create a jboss working directory with a sticky tag that associates the source code with the 2.2 branch. If you look at the jboss/src/main/org/jboss/Main.java file in the jboss working directory that results from the previous command using the cvs status command you will see something like: <pre> bash-2.04$ cd jboss/src/main/org/jboss/ bash-2.04$ cvs status Main.java =================================================================== File: no file Main.java Status: Needs Checkout Working revision: 1.30.2.6 Repository revision: 1.30.2.6 /cvsroot/jboss/jboss/src/main/org/jboss/Main.java,v Sticky Tag: Branch_2_2 (branch: 1.30.2) Sticky Date: (none) Sticky Options: (none) </pre> This shows that the "Sticky Tag:" is set to the Branch_2_2 tag as we requested. <li>Make your chages to the source in the jboss working directory created by the previous check out. <li>Commit your changes. Do this by executing the following command in the directory you made the changes in, or any common parent directory: <pre>cvs commit -m "Your commit msg"</pre> You don't have to specify the commit msg on the commit command line. If you don't you will be prompted for the commit msg. Note that this will apply the same commit msg to all files you have changed. If you want specific commit msgs for each file then you can perform a seperate commit on each file. <li>(Required) Tag the branch with the next beta binary release tag by incrementing the build number of the latest tag. To determine what build number to use, look at all of the tags for a file using the cvs status command with the -v option. For example, looking at jboss/src/main/org/jboss/Main.java again: <pre> bash-2.04$ cvs status -v Main.java =================================================================== File: no file Main.java Status: Needs Checkout Working revision: 1.30.2.6 Repository revision: 1.30.2.6 /cvsroot/jboss/jboss/src/main/org/jboss/Main.java,v Sticky Tag: Branch_2_2 (branch: 1.30.2) Sticky Date: (none) Sticky Options: (none) Existing Tags: Rel_2_3_1_0 (revision: 1.34) Rel_2_2_2_0 (revision: 1.30.2.6) JBoss_2_2_2 (revision: 1.30.2.6) JBoss_2_2_1 (revision: 1.30.2.3) Rel_2_2_1_0 (revision: 1.30.2.3) </pre> The Rel_2_2_2_0 tag is the latest tag on the 2.2 branch and indicates that no patches have been made since the JBoss_2_2_2 release. So to tag the changes you have made you need to use Rel_2_2_2_1. Do this using: <pre>cvs tag Rel_2_2_2_1</pre> from the top of the jboss working directory. <li>(Required) Merge the changes to the main trunk if they are missing. You need to validate that the changes you have made to the release branch are not already in the main trunk and merge the changes if they are. <li>(Required, if merge was done) Check out the latest trunk code: <pre>cvs co jboss</pre> <li>(Required, if merge was done) Tag the main trunk with the next alpha build tag. Assuming the this is Rel_2_3_1_5, you would do: <pre>cvs tag Rel_2_3_1_5</pre> from within the jboss working directory you just checked out. </ul> <jsp:include page="navigation.jsp" flush="true" /> _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
