User: starksm Date: 01/06/18 12:59:50 Modified: . CVSAdmin.jsp Log: Add the missing step of tagging the main cvs branch with the initial alpha devel build tag after the creation of the branch. Revision Changes Path 1.3 +256 -247 newsite/CVSAdmin.jsp Index: CVSAdmin.jsp =================================================================== RCS file: /cvsroot/jboss/newsite/CVSAdmin.jsp,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- CVSAdmin.jsp 2001/06/15 22:37:56 1.2 +++ CVSAdmin.jsp 2001/06/18 19:59:50 1.3 @@ -1,247 +1,256 @@ -<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 -<p class="text">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 -<p class="text">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 -<p class="text">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 -<p class="text">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 -<p class="text">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 -<p class="text"> -<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 -<p class="text">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" /> - +<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 +<p class="text">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 +<p class="text">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 +<p class="text">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 +<p class="text">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 +<p class="text">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 +<p class="text"> +<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> +<li> +Label the main branch with the next initial alpha development build tag: +Rel_<major>_<odd_minor>_0_0. For the case of a 2.2 release case this would +mean that main development would be for a 2.3 cycle and so main should +be tagged with Rel_2_3_0_0 as follows from within the working directory +created in step 1: +<pre> +cvs tag Rel_2_3_0_0 +</pre> +</ol> + +<p class="head">CHECKING IN A PATCH ON A RELEASE BRANCH +<p class="text">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
