commons-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From pste...@apache.org
Subject svn commit: r929359 - /commons/proper/commons-site/trunk/src/site/xdoc/releases/prepare.xml
Date Wed, 31 Mar 2010 01:49:28 GMT
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>



Mime
View raw message