axis-java-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From veit...@apache.org
Subject svn commit: r1034010 - /axis/axis2/java/core/trunk/src/site/xdoc/release-process.xml
Date Thu, 11 Nov 2010 17:51:58 GMT
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-&lt;version&gt;-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>



Mime
View raw message