This chapter describes the JBoss SVN administration policies for managing the SVN repository. Comments or questions regarding these policies should be directed to the JBoss Development forum.
The CVS branching and release management procedures 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.
Releases are tracked using SVN tags that have the following forms:
- Final Binary Releases: JBoss_(major).(even_minor).(patch)
- Beta Binary Releases: Rel__(major).(even_minor).(patch).(build)
- Development Binary Releases(optional): JBoss_(major).(odd_minor).(patch)
- Alpha Development Builds(optional): Rel_(major).(odd_minor).(patch).(build)
- 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.
- 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.
- 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 greater than or equal to 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.
- An 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.
Consider events 1-13 in blue on the following figure:
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.
- This 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.
- This 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.
- This 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.
- This 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.
- This 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.
- This 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.
- This 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.
- This is the release of a development binary. The release is tagged as JBoss_2_3_1 as well as Rel_2_3_1_0 to start the next alpha series. Prior to this there had also been a JBoss_2_3_0 development binary not shown in the diagram.
- This is the creation of a new binary release branch. After some period of development on the 2.3 portion of the trunk(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.
- This 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.
- This 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.
- This 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.
- This 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.
-
Perform a clean check out of the jboss main
branch without any tags to select the latest
code:
svn co https://svn.jboss.org/repos/jbossas/trunk
-
To create a "tag" you simply execute a copy command.
Tag 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:
svn copy https://svn.jboss.org/repos/jbossas/trunk https://svn.jboss.org/repos/jbossas/tags/Rel_2_3_0_0 "Creating a tag"
-
Create the new branch giving it a branch tag of
Branch_(major)_(even_minor). For example, to
create a 2.2 branch, perform the following
within the working directory created by the
previous check out:
svn copy https://svn.jboss.org/repos/jbossas/trunk https://svn.jboss.org/repos/jbossas/branches/Branch_2_2 "Creating a branch"
-
Create a working directory for the new branch by
checking it out using the Branch_2_2 tag:
svn co https://svn.jboss.org/repos/jbossas/branches/Branch_2_2
-
Label the branch working directory with the
initial beta release tag of
Rel_(major)_(even_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:
svn copy https://svn.jboss.org/repos/jbossas/branches/Branch_2_2 https://svn.jboss.org/repos/jbossas/tags/Rel_2_2_0_0 "Creating a branch
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:
-
Checkout the target module in which the changes are to be made. For
example to commit changes to the
jboss module do:
svn co https://svn.jboss.org/repos/jbossas/trunk
- Make your chages to the source in the jboss working directory created by the previous check out.
-
Commit your changes. Do this by executing the following
command in the directory you made the changes in, or any
common parent directory:
svn commit -m "commit-comment"
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.
The procedure defined below will take a developer through the process of creating a branch, making the necessary changes, and merging those changes into the main branch.
svn copy http://svn.jboss.org/repos/test/tags/JBoss_4_0_3_SP1/ http://svn.jboss.org/repos/test/branches/JBoss_4_0_3_SP1_JBAS-1234 -m "Creating a branch for developing a patch"
- Checkout the newly created branch
svn co http://svn.jboss.org/repos/test/branches/JBoss_4_0_3_SP1_JBAS-1234 jbas-1234_local_dir - Make your changes, perform testing, and commit them
svn commit -m "changes required for patch" At this point you may wish to port this patch to the current code line. To do this we will use the svn merge command. The svn merge command requires 3 pieces of information.
- An initial repository tree
- A final repository tree
- A working copy to apply the changes to
Essentially, you are finding the change set between 1 and 2 and applying them to 3. In our case 1 would be the tagged JBoss-4.0.3.SP1 and 2 would be the JBoss-4.0.3.SP1.PATCH branch that you created. 3 would be the current 4.0 branch (which will you need to check out).
Backporting procedure
- checkout a working copy of the 4.0 branch
svn co http://svn.jboss.org/repos/test/branches/Branch_4_0 jboss-4.0
-
apply the changeset between the 4.0.3.SP1 tagged release and your patched branch to your working copy
svn merge http://svn.jboss.org/repos/test/tags/JBoss_4_0_3_SP1 http://svn.jboss.org/repos/test/branches/JBoss_4_0_3_SP1-JBAS-1234 jboss-4.0
- The differences are now applied to your working copy.
Ensure that no conflicts exist and then commit the work to current jboss-4.0 branch
svn commit