Author: psteitz
Date: Wed Mar 31 01:49:27 2010
New Revision: 929359
URL: http://svn.apache.org/viewvc?rev=929359&view=rev
Log:
Some more edits...
Modified:
commons/proper/commons-site/trunk/src/site/xdoc/releases/prepare.xml
Modified: commons/proper/commons-site/trunk/src/site/xdoc/releases/prepare.xml
URL:
http://svn.apache.org/viewvc/commons/proper/commons-site/trunk/src/site/xdoc/releases/prepare.xml?rev=929359&r1=929358&r2=929359&view=diff
==============================================================================
--- commons/proper/commons-site/trunk/src/site/xdoc/releases/prepare.xml
(original)
+++ commons/proper/commons-site/trunk/src/site/xdoc/releases/prepare.xml Wed
Mar 31 01:49:27 2010
@@ -27,8 +27,9 @@
<section name='Introduction'>
<p>
This document contains a mixture of information, advice and examples.
- It is intended to be a recommendation of best practices.
- Official guidelines for ASF releases are found elsewhere.
+ It is intended to be a recommendation of best practices for Commons
components.
+ The instructions provided here are consistent with, but not a
replacement for
+ the <a href="http://www.apache.org/dev/release.html";>ASF Release
Guidlines.</a>
</p>
<p>
The examples below assume that preparation is being made to release
version <em>1.2</em>
@@ -38,13 +39,15 @@
<section name='Build Environments'>
<p>
Commons components are expected to use Maven to build the project website.
Components
- may choose to use either Maven or Ant to build the actual jar files to be
distributed,
+ may choose to use either Maven or Ant to build the actual jar and tar/zip
files to be distributed,
although it is recommended that Maven be used for this. Both approaches
are covered
- below. The version of maven used is assumed to be Maven 2 throughout.
+ below. The version of maven used is assumed to be Maven 2 throughout. At
a minimum, Commons
+ releases <strong>must</strong> include full source distributions packaged
in tar and zip
+ archives.
</p>
<p>
This document assumes that the release is being prepared on a linux/unix
system, and
- that steps are being executed from a command-line. The principles are the
same, however,
+ that steps are being executed from the command-line. The principles are
the same, however,
for a release prepared on other operating systems or using graphical tools.
</p>
</section>
@@ -91,21 +94,20 @@
the component, the more justified a release branch would be.
</p>
<p>
- If a release branch is used then the branch
- should be taken before the release candidate is cut and voted upon.
Whether this is done
- early in the process or later is a judgement call. Taking the branch
early allows development
- to continue on the trunk. However it means that any updates made as part
of the preparations
- for the release will later need to be merged into the trunk code. In
general, commons
- components are small enough (i.e. development rate is low enough) that
the branch can be
- made later in the process (as each release candidate is generated).
+ If a release branch is used then the branch should be taken before any
release candidate is cut.
+ Whether this is done early in the release preparation process or later
is a judgement call.
+ Taking the branch early allows development to continue on the trunk.
However it means that any
+ updates made as part of the preparations for the release will later need
to be merged into the
+ trunk code. In general, commons components are small enough (i.e.
development rate is low enough)
+ that there is no need for a release branch.
</p>
<p>
If a release branch is to be made early, then the following should be
done:
<pre>
cd to the project's base directory in your subversion working copy.
svn update trunk
- svn cp trunk branches/foo-1.2-work
- svn commit -m "Creating foo-1.2-work branch" branches/foo-1.2-work
+ svn cp trunk branches/foo-1.2-release
+ svn commit -m "Creating foo-1.2-release branch"
branches/foo-1.2-release
</pre>
Note that the "svn update" step is necessary in order to ensure that the
directory being
copied does not have a mix of files at various revisions; even if the
files haven't changed
@@ -118,7 +120,7 @@
Including details of the branch strategy in the release plan aids
coordination.
</p>
<p>
- The description below assumes a release is being prepared on the trunk.
The process is nearly
+ The description below assumes a release is being prepared using the code
in trunk. The process is nearly
identical when preparing from a release branch: only the directory in
which the work is
performed is different.
</p>
