Author: bayard
Date: Sat Apr 3 04:53:07 2010
New Revision: 930472
URL: http://svn.apache.org/viewvc?rev=930472&view=rev
Log:
Edited away some lines - focusing on what is done everytime rather than what
potentially might be a good idea
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=930472&r1=930471&r2=930472&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 Sat
Apr 3 04:53:07 2010
@@ -48,7 +48,7 @@
<p>
This document assumes that the release is being prepared on a linux/unix
system, and
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.
+ for a release prepared on other operating systems.
</p>
</section>
@@ -57,58 +57,35 @@
<p>
A commons committer (normally one of the development team) should post
an email to the
development list proposing that a release be made and nominating a
release manager.
- Typically, this should be the proposer. Normal voting procedures apply
- (<a
href='http://www.apache.org/foundation/glossary.html#LazyConsensus'>lazy
consensus</a>).
+ Typically, the proposer volunteers as the release manager and it passes
by
+ <a
href='http://www.apache.org/foundation/glossary.html#LazyConsensus'>lazy
consensus</a>.
</p>
<p>
A release plan should also be prepared, in which the tasks remaining to
be done before
the release are listed. It may be useful to prepare draft release notes
before proposing
the release, so that others can see what changes are expected for the
new release.
- Preparing the required documents before the release and presenting them
for public review
- (as part of the plan) gives a better chance that any problems can be
corrected at an early
- stage.
- </p>
- <p>
- Many release managers favor development of the plan on the
- <a href='http://wiki.apache.org/commons'>wiki</a>.
- This format encourages collaboration between developers and reduces the
overhead
- of maintaining the plan.
- </p>
- <p>
- For complex releases, release managers should consider calling a vote on
the release plan
- (by lazy consensus). This may help to coordinate the execution of the
plan and to ensure
- that all developers are aware of the state of the plan.
</p>
</subsection>
<subsection name='Consider a Release Branch'>
<p>
- Consider whether a release branch is needed before preparing for the new
release.
- During the preparation for a release, the changes made to the code needs
to be tightly
- controlled. The release manager should take particular care in reviewing
all changes.
- If a release branch is not taken then the trunk code will need to be
frozen for
- critical periods and normal development work suspended for the duration.
+ Consider whether a release branch is needed before preparing for the new
release. In general,
+ commons components are small enough that there is no need for a release
branch, but if
+ active development wants to continue on the next version while a release
is being made then
+ trunk should be branched to allow development to continue.
If a release branch is taken then work will be required to merge any
changes back
into the trunk.
- Whether a release branch is needed or not is a judgement call but the
more active
- 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 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.
+ The following is one way to create 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-release
svn commit -m "Creating foo-1.2-release branch"
branches/foo-1.2-release
</pre>
+ <p>
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
since the last svn update this can cause "svn log -v" on the new
directory to report files as
@@ -117,12 +94,8 @@
a clean copy is made.
</p>
<p>
- Including details of the branch strategy in the release plan aids
coordination.
- </p>
- <p>
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.
+ identical when preparing from a release branch: only the directory in
which the work is performed is different.
</p>
</subsection>
<subsection name='Check Compatibility'>
@@ -144,7 +117,7 @@
Check that the javadocs have the correct version number.
</p>
<p>
- If the component uses checkstyle or PMD tools, examine the reports and fix
all
+ If the component uses Checkstyle, FindBugs or PMD tools, examine the
reports and fix any
problems.
</p>
</subsection>
