You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-commits@axis.apache.org by ve...@apache.org on 2010/11/11 18:51:58 UTC
svn commit: r1034010 -
/axis/axis2/java/core/trunk/src/site/xdoc/release-process.xml
Author: veithen
Date: Thu Nov 11 17:51:58 2010
New Revision: 1034010
URL: http://svn.apache.org/viewvc?rev=1034010&view=rev
Log:
AXIS2-4877: Updated the release procedure (maven-release-plugin, Nexus, etc.).
Modified:
axis/axis2/java/core/trunk/src/site/xdoc/release-process.xml
Modified: axis/axis2/java/core/trunk/src/site/xdoc/release-process.xml
URL: http://svn.apache.org/viewvc/axis/axis2/java/core/trunk/src/site/xdoc/release-process.xml?rev=1034010&r1=1034009&r2=1034010&view=diff
==============================================================================
--- axis/axis2/java/core/trunk/src/site/xdoc/release-process.xml (original)
+++ axis/axis2/java/core/trunk/src/site/xdoc/release-process.xml Thu Nov 11 17:51:58 2010
@@ -16,74 +16,200 @@
~ specific language governing permissions and limitations
~ under the License.
-->
-
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-<head>
-<meta name="generator" content=
-"HTML Tidy for Windows (vers 14 June 2007), see www.w3.org" />
-<meta http-equiv="content-type" content="" />
-<title>Axis2 Release Process</title>
-</head>
-<body>
-<h1>Release Process</h1>
-<h3>Cutting a branch</h3>
-<ul>
-<li>When a release is ready to go, release manager (RM) puts
-forward a release plan as per standard Apache process, including
-dates. This gets VOTEd on by the committers. During this period the
-trunk is still the only relevant source base.</li>
-<li>As soon as a release is approved (or even before), RM should
-add the new version into JIRA as a target.</li>
-<li>At the point where we would normally do the "code freeze" for a
-release, the RM cuts a branch named for the release. This branch is
-where the release candidates and releases will happen.</li>
-<li>Ideally a release branch is only around for a week or maybe two
-before the release happens.</li>
-<li>The only things that should EVER get checked into the release
-branch are - 1) bug fixes targeted at the release, 2)
-release-specific updates (documentation, SNAPSHOT removal, etc). In
-particular new functionality does not go here unless it is a
-solution to a JIRA report targeted at the release.</li>
-<li>Normal development continues on the trunk.</li>
-</ul>
-<h3>Dependencies and branches</h3>
-<ul>
-<li>The trunk should always be "cutting edge" and as such should
-usually be pointing at SNAPSHOT versions of all dependencies. This
-allows for continuous integration with our partner projects.</li>
-<li>Soon after a release branch is cut, the RM is responsible for
-removing ALL dependencies on SNAPSHOT versions and replacing them
-with officially released versions. This change happens only on the
-release branch.</li>
-</ul>
-<h3>Managing change and issue resolution with a release branch</h3>
-<ul>
-<li>The RM goes through JIRA issues and sets "fix for" to point to
-both "NIGHTLY" and the new branched release number for the fixes
-that are targeted for the release after the branch is cut.</li>
-<li>In general, the assignee/coder fixes JIRA issues or makes other
-changes *on the trunk*. If the JIRA issue is targeted at the
-release, or upon coder's discretion, they then merge the fix over
-to the release branch.</li>
-<li>This way the trunk is ALWAYS up-to-date, and we don't have to
-worry about losing fixes that have only been made on the release
-branch.</li>
-<li>When the assignee resolves an issue, they confirm it's been
-fixed in both branches, if appropriate.</li>
-</ul>
-<h3>Checking changes into the branch</h3>
-<ul>
-<li>If bug fixes are needed later for a release which has long
-since happened (to fix user issues, etc), those fixes generally
-should also happen on the trunk first assuming the problem still
-exists on the trunk.</li>
-<li>There are only two cases where we would ever check anything
-into the branch without first checking it into the trunk. 1)
-Release specific items (release number references, release notes,
-removal of SNAPSHOTs), and 2) if the trunk has moved on in some
-incompatible way.</li>
-</ul>
-</body>
-</html>
+<document xmlns="http://maven.apache.org/XDOC/2.0"
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:schemaLocation="http://maven.apache.org/XDOC/2.0 http://maven.apache.org/xsd/xdoc-2.0.xsd">
+ <properties>
+ <title>Axis2 Release Process</title>
+ </properties>
+ <body>
+ <h1>Release Process</h1>
+ <macro name="toc"/>
+ <section name="Release process overview">
+ <subsection name="Cutting a branch">
+ <ul>
+ <li>When a release is ready to go, release manager (RM) puts
+ forward a release plan as per standard Apache process, including
+ dates. This gets VOTEd on by the committers. During this period the
+ trunk is still the only relevant source base.</li>
+ <li>As soon as a release is approved (or even before), RM should
+ add the new version into JIRA as a target.</li>
+ <li>At the point where we would normally do the "code freeze" for a
+ release, the RM cuts a branch named for the release. This branch is
+ where the release candidates and releases will happen.</li>
+ <li>Ideally a release branch is only around for a week or maybe two
+ before the release happens.</li>
+ <li>The only things that should EVER get checked into the release
+ branch are - 1) bug fixes targeted at the release, 2)
+ release-specific updates (documentation, SNAPSHOT removal, etc). In
+ particular new functionality does not go here unless it is a
+ solution to a JIRA report targeted at the release.</li>
+ <li>Normal development continues on the trunk.</li>
+ </ul>
+ </subsection>
+ <subsection name="Dependencies and branches">
+ <ul>
+ <li>The trunk should always be "cutting edge" and as such should
+ usually be pointing at SNAPSHOT versions of all dependencies. This
+ allows for continuous integration with our partner projects.</li>
+ <li>Soon after a release branch is cut, the RM is responsible for
+ removing ALL dependencies on SNAPSHOT versions and replacing them
+ with officially released versions. This change happens only on the
+ release branch.</li>
+ </ul>
+ </subsection>
+ <subsection name="Managing change and issue resolution with a release branch">
+ <ul>
+ <li>The RM goes through JIRA issues and sets "fix for" to point to
+ both "NIGHTLY" and the new branched release number for the fixes
+ that are targeted for the release after the branch is cut.</li>
+ <li>In general, the assignee/coder fixes JIRA issues or makes other
+ changes *on the trunk*. If the JIRA issue is targeted at the
+ release, or upon coder's discretion, they then merge the fix over
+ to the release branch.</li>
+ <li>This way the trunk is ALWAYS up-to-date, and we don't have to
+ worry about losing fixes that have only been made on the release
+ branch.</li>
+ <li>When the assignee resolves an issue, they confirm it's been
+ fixed in both branches, if appropriate.</li>
+ </ul>
+ </subsection>
+ <subsection name="Checking changes into the branch">
+ <ul>
+ <li>If bug fixes are needed later for a release which has long
+ since happened (to fix user issues, etc), those fixes generally
+ should also happen on the trunk first assuming the problem still
+ exists on the trunk.</li>
+ <li>There are only two cases where we would ever check anything
+ into the branch without first checking it into the trunk. 1)
+ Release specific items (release number references, release notes,
+ removal of SNAPSHOTs), and 2) if the trunk has moved on in some
+ incompatible way.</li>
+ </ul>
+ </subsection>
+ </section>
+ <section name="Performing a release">
+ <subsection name="Preparation">
+ <ol>
+ <li>Check the consistency between the metadata in <tt>pom.xml</tt> and <tt>modules/parent/pom.xml</tt>.
+ Since the root and parent POMs are different, some of the metadata is duplicated and needs to be synchronized
+ manually. This includes the mailing list addresses, issue tracker information, SCM location, etc.</li>
+ <li>Check that the set of legal (<tt>legal/*.LICENSE</tt>) files corresponds to the set of third party
+ JARs included in the binary distribution.</li>
+ <li>Check that the <tt>apache-release</tt> profile works correctly and produces the required distributions.
+ The profile can be executed as follows:
+ <pre>mvn clean install -Papache-release -Dmaven.test.skip=true</pre></li>
+ <li>Check that the source distribution is buildable.</li>
+ <li>Check that the source tree is buildable with an empty local Maven repository.</li>
+ <li>Update the <tt>release-notes.html</tt> and <tt>src/site/xdoc/index.xml</tt> files with a description
+ of the release.</li>
+ <li>Add an entry for the release in <tt>src/site/xdoc/download.xml</tt>.</li>
+ </ol>
+ </subsection>
+ <subsection name="Pre-requisites">
+ <p>The following things are required to perform the actual release:</p>
+ <ul>
+ <li>A PGP key that conforms to the <a href="http://www.apache.org/dev/release-signing.html">requirements for
+ Apache release signing</a>. To make the release process easier, the passphrase for the code signing key should
+ be configured in <tt>${user.home}/.m2/settings.xml</tt>:
+<pre><![CDATA[<settings>
+ ...
+ <profiles>
+ <profile>
+ <id>apache-release</id>
+ <properties>
+ <gpg.passphrase><!-- key passphrase --></gpg.passphrase>
+ </properties>
+ </profile>
+ </profiles>
+ ...
+</settings>]]></pre></li>
+ <li>The release process uses a Nexus staging repository. Every committer should have access to the corresponding
+ staging profile in Nexus. To validate this, login to <a href="https://repository.apache.org">repository.apache.org</a>
+ and check that you can see the <tt>org.apache.axis2</tt> staging profile. The credentials used to deploy to Nexus
+ should be added to <tt>settings.xml</tt>:
+<pre><![CDATA[<servers>
+ ...
+ <server>
+ <id>apache.releases.https</id>
+ <username><!-- ASF username --></username>
+ <password><!-- ASF LDAP password --></password>
+ </server>
+ ...
+</servers>]]></pre></li>
+ </ul>
+ </subsection>
+ <subsection name="Release">
+ <p>In order to prepare the release artifacts for vote, execute the following steps:</p>
+ <ol>
+ <li>Update the release date in <tt>release-notes.html</tt>, <tt>src/site/xdoc/index.xml</tt> and
+ <tt>src/site/xdoc/download.xml</tt>. Since it is not possible to predict the exact date when the
+ release is officially announced, this should be date when the date when the release tag is created.</li>
+ <li>Temporarily disable the Hudson build(s) for Axis2, in order to avoid accidental deployment of the release
+ candidate to the local repository of a Hudson executor if the release process fails somewhere in the middle and/or
+ a Hudson build starts at the wrong moment.</li>
+ <li>Start the release process using the following command:
+ <pre>mvn release:prepare -Peverything</pre>
+ When asked for a tag name, use the following format: <tt>vX.Y.Z</tt>. The <tt>everything</tt> profile
+ makes sure that the version numbers of all Maven modules are incremented properly.</li>
+ <li>Perform the release using the following command:
+ <pre>mvn release:perform</pre>
+ This command may fail for users in locations that use the EU Subversion server. If this happens,
+ wait for a minute (so that the EU server can catch up with its master) and simply rerun the command.
+ It will continue where the error occurred.</li>
+ <li>Login to Nexus and close the staging repository. For more details about this step, see
+ <a href="https://docs.sonatype.org/display/Repository/Closing+a+Staging+Repository">here</a>.</li>
+ <li>Deploy the distributions to your <tt>public_html</tt> area on <tt>people.apache.org</tt>.
+ The <tt>release:perform</tt> goal should have produced all the necessary files in the
+ <tt>target/axis2-<version>-dists</tt> folder. Please preserve the directory structure and
+ file names because they exactly match the requirements for deployment to <tt>www.apache.org</tt>
+ (see below).</li>
+ <li>Generate and deploy the Maven site to your <tt>public_html</tt> area on <tt>people.apache.org</tt>
+ (either by building the site locally and transfer the files to <tt>people.apache.org</tt>, or by
+ checking out the release tag and building the site directly on <tt>people.apache.org</tt>).</li>
+ <li>Start the release vote by sending a mail to <tt>java-dev@axis.apache.org</tt>.
+ The mail should mention the following things:
+ <ul>
+ <li>The list of issues solved in the release (by linking to the relevant JIRA view).</li>
+ <li>A link to the Nexus staging repository.</li>
+ <li>The URL on <tt>people.apache.org</tt> where the distributions can be downloaded.</li>
+ <li>A link to the preview of the Maven site.</li>
+ </ul>
+ </li>
+ <li>Reenable the Hudson build(s).</li>
+ </ol>
+ <p>If the vote passes, execute the following steps:</p>
+ <ol>
+ <li>Promote the artifacts in the staging repository. See
+ <a href="https://docs.sonatype.org/display/Repository/Releasing+a+Staging+Repository">here</a>
+ for detailed instructions for this step.</li>
+ <li>Login to <tt>people.apache.org</tt> and copy the distributions (including the checksums and
+ signatures) to <tt>/www/www.apache.org/dist/axis/axis2/java/core/</tt>. If you followed the
+ steps described above, then you should already have everything that is needed in your <tt>public_html</tt>
+ folder and you only need to copy the <tt>X.Y.Z</tt> folder to the right location. Please execute the
+ copy with umask 0002 and check that the files and directories have the right permissions (write access for the
+ <tt>axis</tt> group).</li>
+ <li>TODO: instructions to build and update the site</li>
+ </ol>
+ <p>It may take several hours before everything has been synchronized. Before proceeding, check that</p>
+ <ul>
+ <li>the Maven artifacts for the release are available from the Maven central repository;</li>
+ <li>the Maven site has been synchronized;</li>
+ <li>the distributions can be downloaded from the mirror sites.</li>
+ </ul>
+ <p>Once everything is in place, send announcements to <tt>java-user@axis.apache.org</tt> (with copy to
+ <tt>java-dev@axis.apache.org</tt>) and <tt>announce@apache.org</tt>. Since the two lists have different conventions,
+ audiences and moderation policies, it is recommended to send the announcement separately to the two lists.
+ Note that mail to <tt>announce@apache.org</tt> must be sent from an <tt>apache.org</tt> address and will
+ always be moderated. The announcement sent to <tt>announce@apache.org</tt> also should include a general description
+ of Axis2, because not everybody subscribed to that list knows about the project.</p>
+ </subsection>
+ <subsection name="Post-release actions">
+ <ol>
+ <li>Update the DOAP file (<tt>etc/doap_Axis2.rdf</tt>) and add a new entry for the release.</li>
+ <li>Update the status of the release version in JIRA.</li>
+ </ol>
+ </subsection>
+ </section>
+ </body>
+</document>