Author: buildbot
Date: Sun Jan 18 21:46:55 2015
New Revision: 936690
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 Sun Jan 18 21:46:55 2015
@@ -1 +1 @@
-1652764
+1652860
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 Sun Jan 18
21:46:55 2015
@@ -22,7 +22,203 @@
<script type="text/javascript" src="../js/site.js"></script>
- </head>
+ <!-- Disable Xdoclint, until JavaDoc issues are fixed --></p>
+<p></p></div>
+<div class="section">
+<h3></h3>
+<p></p>
+<p></p>
+<div>
+<pre></pre></div>
+<p></p>
+<div>
+<pre></pre></div>
+<p></p>
+<p></p>
+<ol style="list-style-type: decimal">
+<li></li>
+<li></li>
+<li></li>
+<li></li>
+<li>
+<div>
+<pre></pre></div></li>
+<li></li></ol>
+<p></p></div></div>
+<div class="section">
+<h2></h2>
+<div class="section">
+<h3></h3>
+<p></p>
+<ul>
+<li></li>
+<li></li>
+<li></li></ul></div>
+<div class="section">
+<h3></h3>
+<p></p>
+<p></p>
+<p></p>
+<div>
+<pre></pre></div>
+<p></p>
+<p></p>
+<p></p>
+<p></p>
+<p></p></div>
+<div class="section">
+<h3></h3>
+<p></p>
+<p></p>
+<div>
+<pre></pre></div>
+<p></p>
+<div>
+<pre></pre></div>
+<p></p>
+<div>
+<pre></pre></div>
+<p></p></div>
+<div class="section">
+<h3></h3>
+<p></p>
+<p></p>
+<p></p></div>
+<div class="section">
+<h3></h3>
+<p></p>
+<p></p>
+<p></p>
+<p></p>
+<p></p>
+<p></p>
+<p></p>
+<p></p>
+<p></p>
+<p></p>
+<p></p></div>
+<div class="section">
+<h3></h3>
+<p></p>
+<div>
+<pre></pre></div>
+<p></p>
+<p></p></div>
+<div class="section">
+<h3></h3>
+<p></p>
+<p></p>
+<p></p>
+<div class="section">
+<h4></h4>
+<p></p>
+<div>
+<pre></pre></div>
+<p></p>
+<div>
+<pre></pre></div>
+<p></p>
+<p></p>
+<div>
+<pre></pre></div>
+<p></p></div>
+<div class="section">
+<h4></h4>
+<p></p>
+<p></p>
+<div>
+<pre></pre></div>
+<p></p>
+<p></p>
+<div>
+<pre></pre></div>
+<p></p></div></div>
+<div class="section">
+<h3></h3>
+<p></p>
+<p></p>
+<div>
+<pre></pre></div>
+<div>
+<pre></pre></div>
+<p></p>
+<p></p>
+<p></p>
+<p></p>
+<p></p>
+<p></p>
+<div>
+<pre></pre></div>
+<p></p>
+<div>
+<pre></pre></div>
+<p></p></div>
+<div class="section">
+<h3></h3>
+<p></p>
+<div>
+<pre></pre></div>
+<p></p></div></div>
+<div class="section">
+<h2></h2>
+<div class="section">
+<h3></h3>
+<p></p>
+<p></p>
+<div>
+<pre></pre></div>
+<p></p>
+<p></p>
+<p></p>
+<div>
+<pre></pre></div>
+<p></p>
+<p></p></div></div>
+<div class="section">
+<h2></h2>
+<p></p>
+<div class="section">
+<h3></h3>
+<p></p></div>
+<div class="section">
+<h3></h3>
+<ul>
+<li></li>
+<li></li></ul></div>
+<div class="section">
+<h3></h3>
+<p></p></div>
+<div class="section">
+<h3></h3>
+<p></p>
+<p></p>
+<p></p>
+<ul>
+<li></li>
+<li></li></ul>
+<p></p>
+<div>
+<pre></pre></div></div>
+<div class="section">
+<h3></h3>
+<p></p>
+<p></p></div></div>
+<div class="section">
+<h2></h2>
+<div class="section">
+<h3></h3>
+<p></p></div>
+<div class="section">
+<h3></h3>
+<p></p>
+<ul>
+<li></li>
+<li></li>
+<li></li></ul></div></div>
+<div class="section">
+<h2></h2>
+<p></p>
+<p></p></div> </head>
<body class="composite">
<a href=".././" id="bannerLeft"
title="Apache Commons logo">
@@ -265,6 +461,11 @@
Typically, the proposer volunteers as the release manager and it passes
by
<a class="externalLink"
href="http://www.apache.org/foundation/glossary.html#LazyConsensus";>lazy
consensus</a>.
</p>
+ </div>
+
+
+<div class="section">
+<h3><a name="Update_KEYS_file_if_necessary"></a>Update KEYS file if
necessary</h3>
<p>
If the release manager has not yet performed a Commons release, they may
need to add their
@@ -284,6 +485,11 @@
The public key should also be
<a class="externalLink"
href="http://www.apache.org/dev/release-signing.html#keyserver-upload";>uploaded
to a public keyserver</a>.
</p>
+ </div>
+
+
+<div class="section">
+<h3><a name="Create_a_Release_Plan"></a>Create a Release Plan</h3>
<p>
A release plan should also be prepared, in which the tasks remaining to
be done before
@@ -370,847 +576,18 @@
</p>
<p>
- If the component uses checkstyle, findbugs or PMD tools, examine the
reports and fix all
- problems.
- </p>
- </div>
-
-<div class="section">
-<h3><a
name="Configure_the_Build_to_Generate_a_Complete_Set_of_Release_Artifacts"></a>Configure
the Build to Generate a Complete Set of Release Artifacts</h3>
-
-<p>
- For builds using Maven, the contents of the source and binary
distributions are configured
- in assembly descriptors. By convention, these are stored in
src/main/assembly and named
- src.xml and bin.xml, respectively. Names and locations for these files
are specified in
- the maven-assembly-plugin configuration in the pom. Make sure that all
(and only) files
- that should be included in the source and binary distributions are
included in the fileset
- elements of the descriptors. Look at some recently released components'
descriptors for comparison.
- At a minimum, both source and binary distributions <b>must</b> include
the release notes, license and
- notice files.
- </p>
-
-<p>
- Update the version numbers in pom.xml and build.xml to the new release
version, in this example, 1.2.
- For Maven builds, make sure that the build properties are properly set.
Review the <tt>properties</tt>
- section of the pom:
- </p>
-<div>
-<pre>
- <properties>
- <commons.componentid>foo</commons.componentid>
- <commons.release.version>1.2</commons.release.version>
- <commons.rc.version>RC1</commons.rc.version>
-
- <-- properties not related to versioning -->
- <commons.jira.id>FOO</commons.jira.id>
- <commons.jira.pid>007</commons.jira.pid>
- <maven.compile.source>1.3</maven.compile.source>
- <maven.compile.target>1.3</maven.compile.target>
-
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
-
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
- <properties> </pre></div>
-
-
-<p>
- Make sure that the release version is set to the new release and that
the compile and source targets
- are set correctly. Generate and check in a new download page for the
component:
- </p>
-<div>
-<pre>
- mvn commons:download-page
- svn commit -m "Updated download page in preparation for 1.2
release." src/site/xdoc/download_foo.xml </pre></div>
-
- Note that the target directory must exist beforehand, and that for a
multi-module project the <tt>-N</tt>
- (non-recursive) parameter should be specified on the <tt>mvn</tt>
command line.
-
-
-<p>
- When using Ant, typically the Ant "dist" target produces the
source and binary distributions. Included
- files are specified in the target or sub-targets and should be verified
similarly to above.
- </p>
-
-<p>
- Test the "Ant dist" or "mvn assembly:assembly"
command and inspect the tars/zips and jars produced.
- Verify that
- </p>
-<ol style="list-style-type: decimal">
-
-<li> "Ant dist" or "mvn site" succeeds from the unpacked
source distribution.</li>
-
-<li> The jar manifests include LICENSE and NOTICE files and the contents of
these files are correct.</li>
-
-<li> The jar manifests contain <tt>X-Compile-Source-JDK</tt> and
<tt>X-Compile-Target-JDK</tt>
- entries set to the correct values. </li>
-
-<li> The jar manifests include correctly set OSGi bundle properties (ask for
help verifying these on
- commons-dev if necessary). </li>
-
-<li> The jar manifests include the following required properties, set to the
correct values(*):
-
-<div>
-<pre>
- Extension-Name: org.apache.commons.foo
- Specification-Title: Apache Commons Foo
- Specification-Vendor: The Apache Software Foundation
- Specification-Version: 1.2
- Implementation-Vendor-Id: org.apache
- Implementation-Title: org.apache.commons.foo
- Implementation-Vendor: The Apache Software Foundation
- Implementation-Version: 1.2
- Built-By: <your apache ID></pre></div></li>
-
-<li> "mvn site" generates the documentation correctly and all links
are working.</li>
- </ol>
- Do not proceed with tagging or cutting RCs until you have a fully
working build that produces
- a good set of distribution artifacts. If your component supports both
Ant and Maven builds, make
- sure that the build succeeds using both on all supported JDK versions.
If you have access to
- multiple platforms, test the build(s) on as many as you can.
-
-
-<p>
- (*) The default configuration of the build will use the name of the
current logged in user as value for the <tt>Built-By</tt> MANIFEST header. Use
<tt>-Duser.name=<your apache ID></tt> to change this.
- </p>
- </div>
- </div>
-
-
-<div class="section">
-<h2><a name="Creating_a_Release_Candidate"></a>Creating a Release
Candidate</h2>
-
-
-<div class="section">
-<h3><a name="Resolve_Bugs"></a>Resolve Bugs</h3>
-
-<p>
- Resolve all bugs on that version! They can be resolved by:
- </p>
-<ul>
-
-<li>fixing</li>
-
-<li>marking them as <tt>INVALID</tt> or <tt>WONTFIX</tt></li>
-
-<li>changing their fix version to another unreleased version</li>
- </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 > 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 "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.
- 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>
- </div>
-
-<div class="section">
-<h3><a name="Prepare_Release_Notes"></a>Prepare Release Notes</h3>
-
-<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
- 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>
- 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:
- </p>
-<div>
-<pre>
- mvn changes:announcement-generate
- mv target/announcement/foo-release-notes.vm RELEASE-NOTES.txt </pre></div>
-
-<p>The Commons Parent pom has a "release-notes" profile which
automatically sets the output
- file, so you can just run the following instead:
- </p>
-<div>
-<pre>mvn changes:announcement-generate -Prelease-notes
[-Dchanges.version=nnn]</pre></div>
-
-
-<p>The commons parent project ships with a
- <a class="externalLink"
href="http://svn.apache.org/repos/asf/commons/proper/commons-parent/trunk/src/changes/release-notes.vm";>default
- template</a>. If you want to configure your own you need to set
- the following property in the <tt>configuration</tt>
- for the maven-changes-plugin in the pom:
- </p>
-<div>
-<pre>
- <template>foo-release-notes.vm</template>
- </pre></div>
- and the Velocity template, <tt>foo-release-notes.vm</tt> needs to be
defined in
- <tt>src/changes</tt>. If you want to put it into a different directory
- you also want to set the <tt>templateDirectory</tt> property.
-
-<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>
- </div>
-
-<div class="section">
-<h3><a name="Test_Against_Listed_Dependencies"></a>Test Against Listed
Dependencies</h3>
-
-<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 <tt>pom.xml</tt> 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
<tt>java-1.x</tt> profile.
- See <a
href="../commons-parent-pom.html#Testing_with_different_Java_versions">Testing
with different Java versions</a>
- for further details.
- </p>
-
-<p>
- If you are using Ant to execute unit tests, then ensure the Ant
<tt>build.xml</tt> file
- references the same library versions as are listed as dependencies in the
<tt>pom.xml</tt>
- file then execute the unit tests.
- </p>
- </div>
-
-
-<div class="section">
-<h3><a name="Check_the_Apache_License"></a>Check the Apache License</h3>
-
-<p>
- Check the <a class="externalLink"
href="http://www.apache.org/licenses/";>Apache Licenses</a> page for current
information.
- Check that each distribution contains a copy of the license.
- Check that the jar contains a copy of the license in the META-INF
directory.
- </p>
-
-<p>
- Check that the years in the copyright statement in the NOTICE file are
correct.
- </p>
-
-<p>
- Developer documentation on how to apply the Apache License
- can be found in <a class="externalLink"
href="http://www.apache.org/dev/apply-license.html";>Applying the Apache
License, Version 2.0</a>
- and <a class="externalLink"
href="http://www.apache.org/legal/src-headers.html";>ASF Source Header and
Copyright Notice Policy</a>
- </p>
-
-<p>
- Some of the important items from the aforementioned documents:
- </p>
-
-<p>
- <b>Do I have to have a copy of the license in each source file?</b>
Maven builds can use the RAT plugin to
- generate a license report.
- </p>
-
-<p>
- Only one full copy of the license is needed per distribution. Each
source
- file only needs to contain the boilerplate notice at:
- </p>
-
-<p>
- <tt><a class="externalLink"
href="http://www.apache.org/legal/src-headers.html#headers";>http://www.apache.org/legal/src-headers.html#headers</a></tt>
- </p>
-
-<p>
- <b>In my current source files I have attribution notices for other
works.
- Do I put this in each source file now?</b>
- </p>
-
-<p>
- No. The new license allows for a NOTICE file that contains such
attribution
- notices (including the Apache attribution notice). See
- </p>
-
-<p>
- <tt><a class="externalLink"
href="http://www.apache.org/licenses/example-NOTICE.txt";>http://www.apache.org/licenses/example-NOTICE.txt</a></tt>
- </p>
-
-<p>
- for an example that provides all of the notices applicable to the
- httpd-2.0 distribution.
- </p>
- </div>
-
-
-<div class="section">
-<h3><a name="Check_NOTICE.txt"></a>Check NOTICE.txt</h3>
-
-<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:
- </p>
-
-<div>
-<pre>
- Apache Commons {Foo}
- Copyright {earliest}-{latest} The Apache Software Foundation
-
- This product includes software developed at
- The Apache Software Foundation (http://www.apache.org/).
- </pre></div>
-
-<p>Verify <tt>{latest}</tt> is the current year.</p>
-
-<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.
- </p>
- </div>
-
-<div class="section">
-<h3><a name="Tag_the_Release_Candidate"></a>Tag the Release Candidate</h3>
-
-<p>
- 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
- and double check that everything is still fine.
- </p>
-
-<p>
- Make sure that the build version number corresponds to the release
version. For example,
- <tt>commons-foo-1.2</tt>. What you are preparing at this point is a
candidate for release,
- which we will vote on and then push directly to the mirrors. Clean
build, run the unit tests
- and check that the javadocs have the correct version number. Check
in all changes.
- </p>
-
-<p>
- Now create the tag for the release candidate. There are two options
how to do that,
- you can either use the Maven release plugin or create the tag
manually. In either case, record
- the svn revision number, you'll need it for the release vote
mail.</p>
-
-
-<div class="section">
-<h4>Manual Method<a name="Manual_Method"></a></h4>
-
-<p>Create a clean SVN workspace for the release candidate:</p>
-
-<div>
-<pre>
- svn co https://svn.apache.org/repos/asf/commons/proper/foo/trunk
foo-1.2-RC1
- </pre></div>
-
-
-<p>Edit the version fields in the POMs to remove the -SNAPSHOT, for example
- using Maven's version plugin.</p>
-
-<div>
-<pre>
- mvn versions:set -DnewVersion=1.2 -DgenerateBackupPoms=false
- </pre></div>
-
-
-
-<p>Edit the SCM entries in the POM. Note: use the final tag, without any RC
suffix.
- Do <tt>svn diff</tt> and <tt>svn status</tt> 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 as below.
- The tag name should include the component name, as this makes it
easier to distinguish checkouts.
- Try to follow the existing naming convention so the tag names will
sort in a reasonable order.
- For example NET uses NET_M_N_RC1, and LANG has a similar convention.
- For an example of how <b>not</b> to do it, see
https://svn.apache.org/repos/asf/commons/proper/io/tags/
- The IO tags don't sort properly.
- </p>
-
-
-<div>
-<pre>
- svn copy foo-1.2-RC1 -m "Creating foo-1.2-RC1 tag"
https://svn.apache.org/repos/asf/commons/proper/foo/tags/foo-1.2-RC1
- </pre></div>
-
-
-<p>
- Do NOT check the updated workspace back into the development trunk.
- It's important to only have SNAPSHOT versions in trunk; only tags
should have non-SNAPSHOT versions.
- Also, by leaving trunk unchanged, nothing needs to be reverted if the
RC vote fails and the Rc needs to be re-rolled.
- </p>
- </div>
-<div class="section">
-<h4>Maven Release Plugin<a name="Maven_Release_Plugin"></a></h4>
-
-<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>
-
-<div>
-<pre>
- mvn release:prepare -DdryRun=true
- </pre></div>
-
-
-<p>Diff the original file <tt>pom.xml</tt> with the one called
<tt>pom.xml.tag</tt> to see if the license or
- any other info has been removed. This has been known to happen if
the starting <tt><project></tt> tag
- is not on a single line. The only things that should be different
between these files are the <tt><version></tt>
- and <tt><scm></tt> elements. Any other changes, you must
backport yourself to the original
- <tt>pom.xml</tt> file and commit before proceeding with the
release.</p>
-
-
-<p>Remember to do <tt>mvn release:clean</tt> before you start the real release
process.
- If everything is ok, run:</p>
-
-<div>
-<pre>
- mvn release:prepare
- </pre></div>
-
-
-<p>
- The Maven release:prepare goal updates the trunk tag to the next
SNAPSHOT release.
- If the RC vote fails, this will need to be reverted before re-rolling
the RC.
- (the manual method described above avoids this problem)
- </p>
-
- </div></div>
-
-<div class="section">
-<h3><a name="Create_the_Release_Candidate"></a>Create the Release
Candidate</h3>
-
-
-<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
- building, then use the appropriate <tt>java-1.x</tt> profile to ensure
that compilation and testing is done
- with the correct Java version. This will catch any accidental use of
methods etc. that are not in
- the target Java version libraries.
- See <a
href="../commons-parent-pom.html#Testing_with_different_Java_versions">Testing
with different Java versions</a>
- for further details.
- (the compiler.source and compiler.target versions only affect source
syntax and class file format)
- </p>
-
-
-<p>To create all distributables and upload the Maven artifacts to the <a
class="externalLink" href="http://repository.apache.org";>ASF Nexus instance</a>
run
- </p>
-<div>
-<pre>
- mvn deploy -Prelease [-Pjava-1.x]
- </pre></div>
- If you want to do a test deployment first, you can add the following
option:
-
-<div>
-<pre>
- mvn deploy -Prelease -Ptest-deploy [-Pjava-1.x]
- </pre></div>
- The "test-deploy" profile uploads the artifacts to
target/deploy instead of Nexus so one can check all the required files
- have been created with the expected contents.
- Best to run "mvn clean" before doing the live deployment.
- Again remember to use <tt>-Duser.name=<your apache ID></tt> to
make sure the <tt>Built-By</tt> MANIFEST header is correct.
-
-
-<p>This will PGP-sign all artifacts and upload them to a new staging
repository, Nexus itself will create MD5
- and SHA1 checksums for all files that have been uploaded.</p>
-
-<p>A known problem is that gpg signing may fail if the gpg plugin tries to
read the passphrase interactively.
- It works if you specify the passphrase when invoking mvn
(<tt>-Dgpg.passphrase=***</tt>) or run
- <tt>gpg-agent</tt> before starting mvn.</p>
-
-<p>Unfortunately this uploads more than should be part of the Maven
repository, in particular the binary and source
- distribution <tt>.tar.gz</tt> and <tt>.zip</tt> files are there as
well. Before you
- <a class="externalLink"
href="http://www.apache.org/dev/publishing-maven-artifacts.html#close-stage";>close</a>
the staging
- repository you must remove the tarballs/zips together with their PGP
signatures and checksums using
- the Nexus web interface. While
- you are at it you can also remove the checksums Nexus created for the
PGP signatures of the
- remaining artifacts, they are not needed at all.</p>
-
-<p><i>If anybody knows how we can avoid uploading the distributions, please
lend a hand. The manual step is
- not only annoying, uploading the files also wastes time and
bandwidth.</i></p>
-
-<p>Once the unneeded files have been deleted you can now close the staging
repository.</p>
-
-<p>The tarballs and zips need to go to
- <a class="externalLink"
href="https://dist.apache.org/repos/dist/dev/commons/";>https://dist.apache.org/repos/dist/dev/commons/</a>.
If
- this is the first release of foo after svnpubsub has been enabled you
have to create the directory
- structure for your component.</p>
-
-<div>
-<pre>
- svn mkdir -m "Creating initial directory structure for foo"
https://dist.apache.org/repos/dist/dev/commons/foo
- svn mkdir -m "Creating initial directory structure for foo"
https://dist.apache.org/repos/dist/dev/commons/foo/binaries
- svn mkdir -m "Creating initial directory structure for foo"
https://dist.apache.org/repos/dist/dev/commons/foo/source
- </pre></div>
-
-<p>Then check out <tt>https://dist.apache.org/repos/dist/dev/commons/foo</tt>
and copy the tarballs, checksums and
- PGP signatures to the appropriate directories. You can find those
artifacts inside your local Maven repository.
- The procedure will be something like (where <tt>release_path</tt>
points to your working copy of the dist repository):</p>
-
-<div>
-<pre>
- version=1.2
- repo_path=~/.m2/repository/org/apache/commons/commons-foo/${version}
- release_path=~/foo-release
- mkdir -p ${release_path}/binaries
- mkdir -p ${release_path}/source
- cp ${repo_path}/*.bin.zip* ${release_path}/binaries
- cp ${repo_path}/*.bin.tar.gz* ${release_path}/binaries
- cp ${repo_path}/*.src.zip* ${release_path}/source
- cp ${repo_path}/*.src.tar.gz* ${release_path}/source
- cp RELEASE-NOTES.txt ${release_path}
- </pre></div>
-
-<p><tt>svn add</tt> the files and commit them. Again, record the revision
number for the vote email.</p>
- </div>
-
-
-<div class="section">
-<h3><a name="Create_the_Release_Candidate_Website"></a>Create the Release
Candidate Website</h3>
-
-<p>
- The new website should be published in your home directory on
people.apache.org.
- For example:
- </p>
-<div>
-<pre>
- mvn site [-Pjacoco] [-Pcobertura]
- </pre></div>
- 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 <tt>~/public_html/foo-1.2-RC1</tt>.
-
-
-<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>
- </div>
- </div>
-
-
-<div class="section">
-<h2><a name="Voting_On_Release"></a>Voting On Release</h2>
-
-<div class="section">
-<h3><a name="aVOTE_Release_Foo_1.2_based_on_RC1"></a>[VOTE] Release Foo 1.2
based on RC1</h3>
-
-<p>
- Once the release candidate has been created and uploaded, now it's
time to propose the release VOTE.
- </p>
-
-<p>
- Post a <tt>[VOTE] Release Foo 1.2 based on RC1</tt> email to
<b>d...@commons.apache.org</b>.
- This should include links to minimally the distributions, site, tag
and KEYS. Here is an example release VOTE message body:
- </p>
-<div>
-<pre>
- We have fixed quite a few bugs and added some significant enhancements since
Foo 1.1 was released,
- so I would like to release Foo 1.2.
-
- Foo 1.2 RC1 is available for review here:
- https://dist.apache.org/repos/dist/dev/commons/foo/ (svn revision XYZ)
-
- Maven artifacts are here:
-
https://repository.apache.org/content/repositories/orgapachecommons-ABC/org/apache/commons/commons-foo/1.2/
-
- Details of changes since 1.1 are in the release notes:
- https://dist.apache.org/repos/dist/dev/commons/foo/RELEASE-NOTES.txt
- http://people.apache.org/~luckyrm/foo-1.2-RC1/changes-report.html
-
- I have tested this with JDK 1.3, 1.4, 1.5 and 1.6 using maven2.
-
- The tag is here:
- http://svn.apache.org/repos/asf/commons/proper/foo/tags/FOO_1_2_RC1/ (svn
revision)
- N.B. the SVN revision is required because SVN tags are not immutable.
-
- Site:
- http://people.apache.org/~luckyrm/foo-1.2-RC1/
- (note some *relative* links are broken and the 1.2 directories are
- not yet created - these will be OK once the site is deployed)
-
- Clirr Report (compared to 1.1):
- http://people.apache.org/~luckyrm/foo-1.2-RC1/clirr-report.html
-
- RAT Report:
- http://people.apache.org/~luckyrm/foo-1.2-RC1/rat-report.html
-
- KEYS:
- https://www.apache.org/dist/commons/KEYS
-
- Please review the release candidate and vote.
- This vote will close no sooner that 72 hours from now, i.e. after 0400 GMT
31-March 2010
-
- [ ] +1 Release these artifacts
- [ ] +0 OK, but...
- [ ] -0 OK, but really should fix...
- [ ] -1 I oppose this release because...
-
- Thanks!
-
- Lucky RM </pre></div>
-
-
-<p>
- Votes from members of the Commons PMC are binding, however votes from
other committers, users and
- contributors are welcomed.
- If the <tt>[VOTE]</tt> is successful then continue. Release VOTEs
should be left open for a
- minimum of 72 hours so community members have ample opportunity to
download, review and test the
- 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
- 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>
- Once a vote is successful, post a <tt>[RESULT] Release Foo 1.2</tt>
email to
- <b>d...@commons.apache.org</b> as a reply to the original posting.
- This email should contain a summary of the voters/votes that were
cast, eg
- </p>
-<div>
-<pre>
- The following people voted on release Foo 1.2:
- Bob +1
- Sue +1
- Sam +0
- Sandy +1 (non-binding) </pre></div>
-
+ If the code is targetted at Java 7 or before, check that the Javadoc can
still be created using Javadoc 8.
+ Javadoc 8 is a lot stricter about the syntax. Ideally fix all the syntax
errors. However if this is not
+ feasible in the time-scale, consider adding a temporary profile to the pom
to disable the stricter checking:
+ <tt>
+
+ <!-- Temporary hack to suppress Javadoc 8 errors -->
+ <!-- to re-enable the checks, build with -P-javadoc_8 -->
+ javadoc_8
-<p>
- Note that binding the VOTEs recorded need to be clearly designated in
the RESULT.
- This may be done by either stating only the binding votes (and
indicating that to be the case)
- or by adding <tt>(non-binding)</tt> to those which are not.
- It is best practice to indicate how each person voted.
- This allows any mistakes to be caught and corrected early.
- If you do vote, please check the results to ensure that your vote has
been correctly tallied.
- </p>
-
-<p>
- During the course of the VOTE, make sure that one or more of the reviewers
have verified the signatures
- and hash files included with the release artifacts. If no one
specifically mentions having done that during
- the VOTE, ask on the dev list and make sure someone does this before you
proceed with the release.
- </p>
- </div>
- </div>
-
-
-<div class="section">
-<h2><a
name="Things_To_Look_For_When_Inspecting_A_Release_Candidate"></a>Things To
Look For When Inspecting A Release Candidate</h2>
-
-<p>
- There are a number of common things that releases fail on.
- </p>
-
-
-<div class="section">
-<h3><a name="API_Changes"></a>API Changes</h3>
-
-<p>
- Accidental non-compatible API changes in a minor release. The clirr
report
- generated by Maven is very useful in spotting these.
- </p>
- </div>
-
-
-<div class="section">
-<h3><a name="Javadoc"></a>Javadoc</h3>
-
-<ul>
-
-<li>Ensure that the Javadoc tool reports no warnings or errors.</li>
-
-<li>Ensure that all new classes and methods have appropriate @since Javadoc
tags.</li>
- </ul>
- </div>
-
-
-<div class="section">
-<h3><a name="Code_Style"></a>Code Style</h3>
-
-<p>
- Many projects enforce coding styles using the CheckStyle or PMD tools. If
your
- project does this, don't forget to check the output and fix any problems.
- </p>
- </div>
-
-
-<div class="section">
-<h3><a name="Class_File_Format"></a>Class File Format</h3>
- <a name="classfileformat"></a>
-
-<p>
- Building on a more recent JVM than the code will run on. Java class file
- format has changed a number of times over the years, and code compiled
with
- a modern JVM may fail to load in an older JVM with the error message
- "invalid class file format" unless the code is compiled with
appropriate
- options set. If you are using Maven, then ensure that your pom
- has maven.compile.target set to the minimum JVM version your binary is
- intented to support. If you are using Ant, then ensure that the javac
task
- has xml attribute "target" is set to the appropriate JVM
version.
- </p>
-
-<p><b>Maven Build</b></p>
-
-<p>
- The Maven build has been modified to include two <b><i>non
standard</i></b> attributes
- in the jar's manifest to indicate the <tt>maven.compile.source</tt> and
- <tt>maven.compile.target</tt> properties used to create the jar. This
serves two purposes:
- </p>
-<ul>
-
-<li>To provide comfort to users regarding JVM compatibility.</li>
-
-<li>Enable releases to be checked more easily for JVM compatibility.</li>
- </ul>
-
-
-<p>The entries created in the manifest will look something like the following:
- </p>
-<div>
-<pre>
- X-Compile-Source-JDK: 1.3
- X-Compile-Target-JDK: 1.3
- </pre></div>
- These values should be checked to ensure that the release has been built
for the appropriate JVM.
- If they are not present or no values are specified then the
<tt>Build-Jdk</tt> entry should
- be checked to ensure the release has been built with the appropriate JDK.
-
- </div>
-
-
-<div class="section">
-<h3><a name="Licensing"></a>Licensing</h3>
-
-<p>
- The NOTICE.txt file must be included in both the distribution tars/zips
and the
- included jars.
- </p>
-
-<p>
- Maven builds default to including this, so no further effort is required
- for those projects.
- </p>
- </div>
- </div>
-
-
-<div class="section">
-<h2><a name="What_next"></a>What next?</h2>
-
-<div class="section">
-<h3><a name="Vote_succeded"></a>Vote succeded</h3>
-
-<p>
- If the vote succeeded, please see the page <a
href="release.html">Publishing the Release</a>
- </p>
- </div>
-
-
-<div class="section">
-<h3><a name="Vote_failed"></a>Vote failed</h3>
-
-<p>
- If the vote failed, there are various items to tidy up.
- </p>
-<ul>
-
-<li>Drop the Nexus Staging repository.</li>
-
-<li>Delete and files in the dist/dev area.</li>
-
-<li>Do not delete the SVN tag yet unless the release has been completely
abandoned. It can be useful for reviewers to have access to the previous
tag</li>
- </ul>
- If a new RC is to be created, restart the process as described above.
-
- </div>
- </div>
-
-
-<div class="section">
-<h2><a name="Feedback"></a>Feedback</h2>
+ [1.8,)
-<p>
- Feedback - yes please!
- </p>
-<p>
- Comments, critiques and error reports -
- post them any and all to the dev mailing list at commons.apache.org.
Please prefix with [doc].
- </p>
- </div>
-
-
</td>
</tr>
</table>
