Scott!
I repeat, I am almost done with the website...
stop commiting to the website
marcf
PS: damn I will send an email
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of
|[EMAIL PROTECTED]
|Sent: Wednesday, June 13, 2001 3:02 PM
|To: [EMAIL PROTECTED]
|Subject: [JBoss-dev] CVS update: newsite/business CVSAdmin.html
|
|
| 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-develop
ment 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
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
