Author: buildbot
Date: Tue Jan  6 20:29:15 2015
New Revision: 935304

Log:
Staging update by buildbot for commons

Modified:
    websites/staging/commons/trunk/content/   (props changed)
    websites/staging/commons/trunk/content/releases/prepare.html

Propchange: websites/staging/commons/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Tue Jan  6 20:29:15 2015
@@ -1 +1 @@
-1649900
+1649938

Modified: websites/staging/commons/trunk/content/releases/prepare.html
==============================================================================
--- websites/staging/commons/trunk/content/releases/prepare.html (original)
+++ websites/staging/commons/trunk/content/releases/prepare.html Tue Jan  6 
20:29:15 2015
@@ -494,7 +494,79 @@
         </ul>
         
     </div>
+    
+<div class="section">
+<h3><a name="Check_the_commit_log"></a>Check the commit log</h3>
+      
+<p>
+        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, <tt>changes.xml</tt>.  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:
+      </p>
+      
+<p>
+        Get a list of all the commits since the last release by following 
these steps.
+        <br />
+        Assuming that, as part of the last release, a directory 
{project-base}/tags/foo-1.1
+        had been created:
+        </p>
+<div>
+<pre>
+          cd {project-base}/tags
+
+          svn log --stop-on-copy foo-1.1
+          # The last revision NNNN reported in the log output is the revision 
that was
+          # copied to create the tag. If this is a true tag directory, then of 
course
+          # there will only be one revision listed by the log command..
 
+          cd ..
+          svn log -v -rNNNN:HEAD trunk &gt; commits-since-last-release.txt
+        </pre></div>
+      
+      
+<p>
+        This will result in a file that contains info on each commit that 
affected at
+        least one file within the trunk directory since the last release. Note 
that if
+        a commit affected a group of files of which some were outside the 
trunk directory,
+        then they will be included with the associated commit message but can 
be ignored.
+      </p>
+      
+<p>
+        Using &quot;svn diff&quot; instead of &quot;svn log -v&quot; will 
result instead in a file that shows the
+        actual diffs for each file instead of the commit messages. This may be 
more convenient
+        when the commit messages are not sufficiently detailed to be able to 
build the release
+        notes directly from them.
+      </p>
+      
+<p>
+        Inspect the list of changes and enter relevant information into the 
release notes;
+        this may require inspecting the actual changes using &quot;svn 
diff&quot;.
+        Enhancements and new features need to be collated by topic.
+        Bugs fixed should be listed separately together with a short summary 
of the bug.
+      </p>
+      
+<p>
+        Please remember to spell check the release notes. Please break lines 
at 80 characters.
+      </p>
+      
+<p>
+        <b>IMPORTANT!</b> At the current time, selecting by date in subversion 
within the
+        ASF repository isn't reliable. The reason is that when converting a 
date to a revision
+        number, subversion assumes that revision N has an earlier date than 
revision N+M, and
+        that it can therefore perform a binary search on revision numbers to 
locate one with
+        the required date. However CVS imports of data that retain the 
original date
+        information from CVS break this assumption. And unfortunately because 
revisions
+        are repository-wide information, this affects date-based searches
+        even in directories unrelated to the ones that CVS stuff was imported 
into.
+        So while dates are reported correctly in &quot;svn log&quot; output, 
only revision numbers should
+        be used with the -r option. See issue #752 in the subversion issue 
tracker at tigris.org.
+      </p>
+    </div>
     
 <div class="section">
 <h3><a name="Prepare_Release_Notes"></a>Prepare Release Notes</h3>
@@ -549,80 +621,6 @@
     read easily without word wrap.
     </p>
   </div>
-  
-<div class="section">
-<h3><a name="Check_the_commit_log"></a>Check the commit log</h3>
-  
-<p>
-        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, <tt>changes.xml</tt>.  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:
-        </p>
-        
-<p>
-        Get a list of all the commits since the last release by following 
these steps.
-        <br />
-        Assuming that, as part of the last release, a directory 
{project-base}/tags/foo-1.1
-        had been created:
-        </p>
-<div>
-<pre>
-      cd {project-base}/tags
-
-      svn log --stop-on-copy foo-1.1
-      # The last revision NNNN reported in the log output is the revision that 
was
-      # copied to create the tag. If this is a true tag directory, then of 
course
-      # there will only be one revision listed by the log command..
-
-      cd ..
-      svn log -v -rNNNN:HEAD trunk &gt; commits-since-last-release.txt
-        </pre></div>
-        
-        
-<p>
-        This will result in a file that contains info on each commit that 
affected at
-        least one file within the trunk directory since the last release. Note 
that if
-        a commit affected a group of files of which some were outside the 
trunk directory,
-        then they will be included with the associated commit message but can 
be ignored.
-        </p>
-        
-<p>
-        Using &quot;svn diff&quot; instead of &quot;svn log -v&quot; will 
result instead in a file that shows the
-        actual diffs for each file instead of the commit messages. This may be 
more convenient
-        when the commit messages are not sufficiently detailed to be able to 
build the release
-        notes directly from them.
-        </p>
-        
-<p>
-        Inspect the list of changes and enter relevant information into the 
release notes;
-        this may require inspecting the actual changes using &quot;svn 
diff&quot;.
-        Enhancements and new features need to be collated by topic.
-        Bugs fixed should be listed separately together with a short summary 
of the bug.
-        </p>
-        
-<p>
-        Please remember to spell check the release notes. Please break lines 
at 80 characters.
-        </p>
-        
-<p>
-        <b>IMPORTANT!</b> At the current time, selecting by date in subversion 
within the
-        ASF repository isn't reliable. The reason is that when converting a 
date to a revision
-        number, subversion assumes that revision N has an earlier date than 
revision N+M, and
-        that it can therefore perform a binary search on revision numbers to 
locate one with
-        the required date. However CVS imports of data that retain the 
original date
-        information from CVS break this assumption. And unfortunately because 
revisions
-        are repository-wide information, this affects date-based searches
-        even in directories unrelated to the ones that CVS stuff was imported 
into.
-        So while dates are reported correctly in &quot;svn log&quot; output, 
only revision numbers should
-        be used with the -r option. See issue #752 in the subversion issue 
tracker at tigris.org.
-        </p>
-    </div>
-
     
 <div class="section">
 <h3><a name="Test_Against_Listed_Dependencies"></a>Test Against Listed 
Dependencies</h3>    


Reply via email to