User: starksm
Date: 01/06/13 12:01:58
Added: business CVSAdmin.html
Log:
Initial draft of the cvs versioning and branching policies
Revision Changes Path
1.1 newsite/business/CVSAdmin.html
Index: CVSAdmin.html
===================================================================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>JBoss CVS Administration Policy</title>
</head>
<body>
<h1>Introduction</h1>
<p>
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>
<h1>Creating and Managing Release Branches</h1>
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.
<h2>Release Numbering</h2>
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>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>
<p>
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>
<p>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>
<p>
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>
<h2>Example Release Scenarios</h2>
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
<li>
Event 10
<li>
Event 11
<li>
Event 11
</ol>
<h1>CVS Release Task Details</h1>
<h2>Creating a new binary release branch</h2>
<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>
</body>
</html>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
