commons-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bay...@apache.org
Subject svn commit: r930472 - /commons/proper/commons-site/trunk/src/site/xdoc/releases/prepare.xml
Date Sat, 03 Apr 2010 04:53:08 GMT
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>



Mime
View raw message