Author: britter
Date: Tue Jan 6 18:46:57 2015
New Revision: 1649900
URL: http://svn.apache.org/r1649900
Log:
Replace tabs with spaces
Modified:
commons/cms-site/trunk/content/xdoc/releases/prepare.xml
Modified: commons/cms-site/trunk/content/xdoc/releases/prepare.xml
URL:
http://svn.apache.org/viewvc/commons/cms-site/trunk/content/xdoc/releases/prepare.xml?rev=1649900&r1=1649899&r2=1649900&view=diff
==============================================================================
--- commons/cms-site/trunk/content/xdoc/releases/prepare.xml (original)
+++ commons/cms-site/trunk/content/xdoc/releases/prepare.xml Tue Jan 6
18:46:57 2015
@@ -25,12 +25,12 @@
<body>
<section name='Introduction'>
- <p>
- This document contains a mixture of information, advice and examples.
- 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
Guidelines.</a>
- </p>
+ <p>
+ This document contains a mixture of information, advice and examples.
+ 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
Guidelines.</a>
+ </p>
<p>The Apache Commons project uses the Nexus installation at the Apache
Software Foundation to stage Maven artifacts
before the release and later publish them; the Commons Parent POM contains
all the necessary configuration.
This guide covers deploying to Nexus using Maven. For alternatives see
@@ -129,19 +129,19 @@
</p>
</subsection>
<subsection name='Check Compatibility'>
- <p>
+ <p>
Consult the <a href='versioning.html'>Commons Versioning Guidelines</a>
and check
that the current level of compatibility is suitable for the proposed
version number.
Check the current level of compatibility in the code. Tools like
<a href='http://clirr.sourceforge.net'>Clirr</a> and
<a href='http://www.jdiff.org'>JDiff</a> are very useful. Both support Ant
and Maven.
- </p>
+ </p>
</subsection>
<subsection name='Check Javadocs And Code Style'>
- <p>
+ <p>
Ensure all new classes and methods have <code>@since</code> tags.
Compatibility reports produced in the last section may prove helpful.
- </p>
+ </p>
<p>
Ensure no errors or warnings are reported by the Javadoc tool.
Check that the Javadocs have the correct version number.
@@ -244,21 +244,21 @@
<subsection name='Prepare Release Notes'>
<p>
- Each component should have a file RELEASE-NOTES.txt in the base
directory of the component.
- This file should be updated for the release and checked in prior to
tagging or rolling
- the release candidate. As noted above, this file should be included in
both the source
- and binary release distributions. The release notes should contain a
description of all
+ Each component should have a file RELEASE-NOTES.txt in the base directory
of the component.
+ This file should be updated for the release and checked in prior to
tagging or rolling
+ the release candidate. As noted above, this file should be included in
both the source
+ and binary release distributions. The release notes should contain a
description of all
the changes since the previous release. Any compatibility issues with the
last release
(whether binary or semantic) should be highlighted. If there are no
compatibilty issues,
this too should be mentioned. An introduction to the release may also be
given, describing
the component and the release in general terms. The release notes should
contain the minimum
target Java version for the component.
- </p>
+ </p>
<p>
- Components that use the Maven changes plugin and changes.xml to track
changes can generate
- a "starter" release notes document by supplying a custom Velocity
template to the Maven
- announcements plugin:
- <pre>
+ Components that use the Maven changes plugin and changes.xml to track
changes can generate
+ a "starter" release notes document by supplying a custom Velocity template
to the Maven
+ announcements plugin:
+ <pre>
mvn changes:announcement-generate
mv target/announcement/foo-release-notes.vm RELEASE-NOTES.txt </pre></p>
<p>The Commons Parent pom has a "release-notes" profile which
automatically sets the output
@@ -276,15 +276,15 @@
and the Velocity template, <code>foo-release-notes.vm</code> needs to be
defined in
<code>src/changes</code>. If you want to put it into a different directory
you also want to set the <code>templateDirectory</code> property.</p>
- <p>
- The release notes should be a plain text file. Take care to ensure
- that the format allows easy reading on a wide variety of platforms.
- Long lines may need to be broken manually to allow them to be easily
- read easily without word wrap.
- </p>
+ <p>
+ The release notes should be a plain text file. Take care to ensure
+ that the format allows easy reading on a wide variety of platforms.
+ Long lines may need to be broken manually to allow them to be easily
+ read easily without word wrap.
+ </p>
</subsection>
<subsection name='Check the commit log'>
- <p>
+ <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
@@ -309,59 +309,59 @@
cd ..
svn log -v -rNNNN:HEAD trunk > commits-since-last-release.txt
</pre>
- </p>
- <p>
+ </p>
+ <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 "svn diff" instead of "svn log -v" 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>
+ Using "svn diff" instead of "svn log -v" 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 "svn diff".
- Enhancements and new features need to be collated by topic.
+ this may require inspecting the actual changes using "svn diff".
+ 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 "svn log" output, only
revision numbers should
- be used with the -r option. See issue #752 in the subversion issue
tracker at tigris.org.
- </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 "svn log" output, only
revision numbers should
+ be used with the -r option. See issue #752 in the subversion issue
tracker at tigris.org.
+ </p>
</subsection>
<subsection name='Test Against Listed Dependencies'>
- <p>
- If you are using Maven to execute the unit tests associated with the
component then
- there is nothing to do here; Maven will automatically perform the tests
using the
- library versions specified in the <code>pom.xml</code> file.
+ <p>
+ If you are using Maven to execute the unit tests associated with the
component then
+ there is nothing to do here; Maven will automatically perform the tests
using the
+ library versions specified in the <code>pom.xml</code> file.
</p>
<p>
It's also vital to ensure that you test against the correct version of the
Java libraries.
If Maven requires a later version of Java, then use the appropriate
<code>java-1.x</code> profile.
See <a
href="../commons-parent-pom.html#Testing_with_different_Java_versions">Testing
with different Java versions</a>
for further details.
- </p>
+ </p>
<p>
If you are using Ant to execute unit tests, then ensure the Ant
<code>build.xml</code> file
- references the same library versions as are listed as dependencies in
the <code>pom.xml</code>
- file then execute the unit tests.
- </p>
+ references the same library versions as are listed as dependencies in the
<code>pom.xml</code>
+ file then execute the unit tests.
+ </p>
</subsection>
<subsection name='Check the Apache License'>
@@ -411,9 +411,9 @@
<subsection name='Check NOTICE.txt'>
<p>
- The component should contain a NOTICE.txt (next to the LICENSE.txt).
- If this is not present, it must be created.
- The basic content (excepting external attributes notes) should be:
+ The component should contain a NOTICE.txt (next to the LICENSE.txt).
+ If this is not present, it must be created.
+ The basic content (excepting external attributes notes) should be:
</p>
<pre>
Apache Commons {Foo}
@@ -511,7 +511,7 @@
<subsection name="Create the Release Candidate">
<p>
- Build distributions from a fresh checkout of the RC tag.
+ 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
building, then use the appropriate <code>java-1.x</code> profile to ensure
that compilation and testing is done
@@ -579,7 +579,7 @@
<subsection name='Create the Release Candidate Website'>
<p>
- The new website should be published in your home directory on
people.apache.org.
+ The new website should be published in your home directory on
people.apache.org.
For example:
<pre>
mvn site [-Pjacoco] [-Pcobertura]
@@ -587,12 +587,12 @@
The optional "jacoco" and "cobertura" profiles are used to select the
appropriate code coverage tool if required.
Then tar or zip the site in target/site and scp and unpack the files
on people.apache.org in a directory
<code>~/public_html/foo-1.2-RC1</code>.
- </p>
- <p>
- Note that when verifying this candidate site you need to be careful of
absolute
- URLs; following these will lead to the currently published site, not to
the
- equivalent page on the new site being evaluated.
- </p>
+ </p>
+ <p>
+ Note that when verifying this candidate site you need to be careful of
absolute
+ URLs; following these will lead to the currently published site, not to the
+ equivalent page on the new site being evaluated.
+ </p>
</subsection>
</section>
@@ -658,19 +658,19 @@
release candidate. It is a good practice to, as above, specify the
closing time of the VOTE in
the VOTE message.
</p>
- <p>
- If the vote fails, then fix the problem and create a new release
candidate (including creating another tag;
- tags are cheap!). Then call another vote. Creating a perfect release
isn't easy, and it is quite common for
+ <p>
+ If the vote fails, then fix the problem and create a new release candidate
(including creating another tag;
+ tags are cheap!). Then call another vote. Creating a perfect release isn't
easy, and it is quite common for
the first few release candidates to fail, particularly on simple issues
like missing license files. Don't
take negative feedback on RCs personally. The release belongs to the
community and we are all accountable
for anything wrong or lacking in the code we release. That's why
suggestions for improvement are more often than not
accompanied by patches and/or commits to fix problems. Always start a new
VOTE thread to vote on a new RC.
- </p>
+ </p>
<p>
Once a vote is successful, post a <code>[RESULT] Release Foo
1.2</code> email to
<strong>d...@commons.apache.org</strong> as a reply to the original
posting.
This email should contain a summary of the voters/votes that were
cast, eg
- <pre>
+ <pre>
The following people voted on release Foo 1.2:
Bob +1
Sue +1
