commons-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r1457385 - /commons/cms-site/trunk/content/xdoc/releases/prepare.xml
Date Sun, 17 Mar 2013 06:45:12 GMT
Author: bodewig
Date: Sun Mar 17 06:45:12 2013
New Revision: 1457385

merge wiki UsingNexus part on tagging into the page


Modified: commons/cms-site/trunk/content/xdoc/releases/prepare.xml
--- commons/cms-site/trunk/content/xdoc/releases/prepare.xml (original)
+++ commons/cms-site/trunk/content/xdoc/releases/prepare.xml Sun Mar 17 06:45:12 2013
@@ -279,13 +279,14 @@
 	read easily without word wrap.		
-  <subsection name='Checking the commit log'>
+  <subsection name='Check the commit log'>
         Different components have their own ways of creating the change log. 
         The most common, and recommended, way, is to record all significant
         changes in JIRA tickets and include entries in the Maven change-log
-        file, <code>changes.xml</code>.  
-        Here's a way to get the information directly from svn if no change log
+        file, <code>changes.xml</code>.  If your component has a change-log you
+        can skip this step.</p>  
+        <p>Here's a way to get the information directly from svn if no change log
         has been maintained for the component:
@@ -417,14 +418,14 @@
 	This product includes software developed by
 	The Apache Software Foundation (
-      <p>Verify <code>{latest}</code> is the current year</p>
+      <p>Verify <code>{latest}</code> is the current year.</p>
         The NOTICE.txt must be distributed along with the LICENSE.txt.
         Check that the distribution build correctly adds this file
         to the distributions and that the copyright start and end dates are correct.
-    <subsection name='Create the Release Candidate'>
+    <subsection name='Tag the Release Candidate'>
         Once all the preparations agreed in the release plan has been completed, create a
Release Candidate. 
         Before creating the tag from which the release candidate will be generated, run the
distribution build
@@ -437,28 +438,58 @@
         and check that the javadocs  have the correct version number.  Check in all changes.
-        Now create the tag for the release candidate. For example (cutting the candidate
from the trunk):
-		</p>
-	<pre>
-	  svn update trunk
-	  svn cp trunk tags/FOO_1_2_RC1
-	  svn commit -m "Tagging foo-1.2 RC1" tags/FOO_1_2_RC1 </pre>
-        <p>
-        Note that the "svn update" step is necessary in order to ensure that the directory
-        copied does not have a mix of files at various revisions; even if the files haven't
-        since the last svn update this can cause "svn log -v" on the new directory to report
files as
-        having been (R)eplaced.
-	</p>
-	<p>Alternatively, use "svn cp URLsrc URLtag"</p> 
+          Now create the tag for the release candidate.  There are two options how to do
+          you can either use the Maven release plugin or create the tag manually.</p>
+      <subsection name="Manual Method">
+        <p>Create a clean SVN workspace for the release candidate:</p>
-        svn cp  -m "Creating foo-1.2-release branch" \
-   \
+      svn co foo-m.n.o-RC1
-      <p>which will copy files internally within the repository without using the local
working copy: 
-      this always ensures a clean copy is made.
-    </p>
-	<p>
+        <p>Edit the version fields in the POMs to remove the -SNAPSHOT, for example
+        using Maven's version plugin.</p>
+      <pre>
+      mvn versions:set -DnewVersion=3.1 -DgenerateBackupPoms=false
+      </pre>
+        <p>Edit the SCM entries in the parent POM. Note: use the final tag, without
any RC suffix.
+        Do <code>svn diff</code> and <code>svn status</code> to check
that the changes are OK.
+        These should only show changes to the POMs.</p>
+        <p>Create the RC tag, by copying the tag workspace to SVN:</p>
+      <pre>
+      svn copy foo-m.n.o-RC1 -m "Creating foo-m.n.o-RC1 tag"
+      </pre>
+      </subsection>
+      <subsection name="Maven Release Plugin">
+        <p>When using the release plugin, please verify that your poms will not lose
content when they are rewritten during the
+          release process.</p>
+        <p>Inside the branch you are cutting the release from start with</p>
+      <pre>
+      mvn release:prepare -DdryRun=true
+        </pre>
+        <p>Diff the original file <code>pom.xml</code> with the one called
<code>pom.xml.tag</code> to see if the license or
+          any other info has been removed. This has been known to happen if the starting
<code>&lt;project&gt;</code> tag
+          is not on a single line. The only things that should be different between these
files are the <code>&lt;version&gt;</code>
+          and <code>&lt;scm&gt;</code> elements. Any other changes, you
must backport yourself to the original
+          <code>pom.xml</code> file and commit before proceeding with the release.</p>
+        <p>Remember to do <code>mvn release:clean</code> before you start
the real release process.
+          If everything is ok, run:</p>
+      <pre>  
+      mvn release:prepare
+      </pre>
+      </subsection>
+    </subsection>
+    <subsection name="Create the Release Candidate">
+        <p>
 	Build distributions from a fresh checkout of the RC tag.
     Build the code with the target version of Java if possible.<br />
     If the version of Maven you are using requires a more recent version of Java than the
code you are

View raw message