You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@uima.apache.org by sc...@apache.org on 2013/08/05 21:39:57 UTC
svn commit: r1510683 - in /uima/site/trunk/uima-website:
docs/checklist-release.html docs/release.html xdocs/checklist-release.xml
xdocs/release.xml xdocs/staging/osgi.xml xdocs/staging/testing-builds.xml
Author: schor
Date: Mon Aug 5 19:39:57 2013
New Revision: 1510683
URL: http://svn.apache.org/r1510683
Log:
no jira, update release procedures with some more detail, from things I forgot to do :-)
Removed:
uima/site/trunk/uima-website/xdocs/staging/osgi.xml
uima/site/trunk/uima-website/xdocs/staging/testing-builds.xml
Modified:
uima/site/trunk/uima-website/docs/checklist-release.html
uima/site/trunk/uima-website/docs/release.html
uima/site/trunk/uima-website/xdocs/checklist-release.xml
uima/site/trunk/uima-website/xdocs/release.xml
Modified: uima/site/trunk/uima-website/docs/checklist-release.html
URL: http://svn.apache.org/viewvc/uima/site/trunk/uima-website/docs/checklist-release.html?rev=1510683&r1=1510682&r2=1510683&view=diff
==============================================================================
--- uima/site/trunk/uima-website/docs/checklist-release.html (original)
+++ uima/site/trunk/uima-website/docs/checklist-release.html Mon Aug 5 19:39:57 2013
@@ -187,6 +187,19 @@
<li>Do <a href="one-time-release-setup.html">one-time setup</a> required for releasing.</li>
<li>Finish up any changes, close Jiras, assign Jiras to proper release(s).</li>
<li>Update the READMEs and RELEASE-NOTES.</li>
+ <li>Make a new build directory for this release, and svn export the trunk. This is so you can
+ preserve the build for later upload of selected artifacts to the distribution spot.
+ If instead you are building from an existing checkout, do a svn update to be sure the workspace is up-to-date.</li>
+ <li>Purge your local maven repository of artifacts being built by running in the
+ top level directory you'll be building from:
+ <br /><br />
+ <code>mvn dependency:purge-local-repository</code><br /><br />
+ Note that this will immediately re-resolve the dependencies from the maven repositories
+ you have configured.
+ </li>
+ <li>Try a full build: mvn deploy</li>
+ <li>If retrying a release candidate, delete the old rc-xxx in svn xxx/tags/</li>
+ <li>If retrying a release candidate, <code><b>close</b></code> (and <code><b>drop</b></code> as appropriate) any previous repository.apache.org staging repo</li>
<!--li>(If remerging a branch: Note- best to do these if possible at the root of aggregations,
outside of Eclipse, so svn "batching" can work - will be quite a bit fraster)
<ol><li>update branch working copy to head</li>
@@ -201,8 +214,7 @@
<p>More details on next steps are
<a href="http://maven.apache.org/developers/release/apache-release.html">here</a></p>
<ol>
- <p>Make sure you've not left open a previous release candidate staging repository.
- Then release one or more artifacts into the Apache Nexus staging repository.
+ <p>Release one or more artifacts into the Apache Nexus staging repository.
You can do multiple release:prepare/perform steps, with subsequent steps
depending on the previous artifacts in their "release" version.</p>
<li>Do next steps in top release artifact (single module, or mult-module top project).
@@ -214,7 +226,6 @@
For multi-module projects, where all the submodules have the same version, use: <br />
<code>mvn release:prepare -DdryRun -DautoVersionSubmodules</code>.
<li><code>mvn release:clean</code> to restore projects</li>
- <li><code>mvn deploy</code> to deploy snapshot</li>
<li><code>mvn release:prepare [-DautoVersionSubmodules]</code>.
Try to accept the default suggestions for names; you might change the SVN tag to include a "-rc1"
suffix indicating a release candidate number.</li>
@@ -235,6 +246,9 @@
depend on the release version of previous steps. When you're done, you will have 1 or more
"closed" staging repositories, each having a unique URL.
</li-->
+ <li>If necessary, run mvn release:prepare on the eclipse update site. This will create the svn tag,
+ and create the needed artifacts in the target/eclipse-update-site.
+ No need to run release:perform because no artifacts from this are going to Maven central distribution.</li>
<li>Copy any artifacts (together with their signings) to the staging spot. This is typically
in your people.apache.org/~[userid]/public_html directory. For releases which include eclipse-update-site
packagings, this should include any modifications to the composite update site or subsites (see
@@ -243,11 +257,17 @@
<li>Send [VOTE] message to dev list. List the staging repository that testers
will need to add to their <code>settings.xml</code> files, and the distribution SVN repo link.</li>
<li>Post RESULT message</li>
- <li>Delete any artifacts from the staging repo that aren't supposed to go to Maven Central
- (currently only the bin.tar artifacts - the bin.zip is used for building uima-as)</li>
+ <li>Delete any artifacts from the staging repo that aren't supposed to go to Maven Central (if any).
+ The uimaj build doesn't put the bin.zip or bin.tar artifacts on the staging repo, but
+ other builds might need some cleanup.
+ </li>
<li>Promote the release(s) from the staging repositories</li>
- <li>Add the approved staged artifacts to the release/uima spot: log onto people.a.o and do an svn add
- of the actual staged signed artifacts.</li>
+ <li>Add the approved staged artifacts to the release/uima spot.
+ Do an svn add on the bin (zip and tar) and source-release files and their sigs.
+ Do not add files like POMs which have line-endings, if they have signatures; the files added should
+ be "binary" style files. (The line endings (if you build on windows) will be changed upon upload to svn,
+ which will result in bad signatures).
+ </li>
<li>update the UIMA website docs/d with any generated docs, in a manner to
<a href="saving-svn-resources.html">minimize SVN space</a> use, if possible.
This includes: PDFs, HTML versions of docbooks plus the index.html; all go on the
Modified: uima/site/trunk/uima-website/docs/release.html
URL: http://svn.apache.org/viewvc/uima/site/trunk/uima-website/docs/release.html?rev=1510683&r1=1510682&r2=1510683&view=diff
==============================================================================
--- uima/site/trunk/uima-website/docs/release.html (original)
+++ uima/site/trunk/uima-website/docs/release.html Mon Aug 5 19:39:57 2013
@@ -427,8 +427,7 @@ A previous version of this page, with th
<tr><td>
<blockquote class="subsectionBody">
<p>This step is skipped, unless the build tooling is being updated.</p>
- <p>There are two projects in the build tooling, each having as a parent, the common Apache Parent POM
- <b>uima-build-resources</b> and <b>parent-pom</b>.
+ <p>There are several projects in the build tooling.
The following special procedure is used to release updates to these.
</p>
<p>
@@ -470,7 +469,7 @@ A previous version of this page, with th
<p>The release:perform checks out the tag and builds/tests/installs and deploys it to the
NEXUS staging repository.
</p>
- <p>During this process, the release plugin asks what the next levels should be and what the tag name
+ <p>During release:prepare, the release plugin asks what the next levels should be and what the tag name
should be, and unless there's a good reason, we take the defaults (by just hitting enter).
The exception to this is in naming the SVN TAG - normally we have "release candidates".
The recommended convention is to take the suggested name and add "-rc1" for release candidate 1,
@@ -479,7 +478,7 @@ A previous version of this page, with th
<p>The release plugin automatically signs everything that needs signing using gpg. It also
builds the sources.jar, and one overall (for multi-module projects) source-release.zip file,
which can be later obtained and
- should be a copy of the SVN tag for that artifact, and once unzipped, should be buildable,
+ should be an (approximate) copy of the SVN tag for that artifact, and once unzipped, should be buildable,
using <code>mvn install</code>.
</p>
<p>Steps:
@@ -497,7 +496,7 @@ A previous version of this page, with th
<li>
Do a trial build of the release candidate:
<pre>cd **directory for doing the release**
-mvn install -Papache-release</pre>
+ mvn deploy -Papache-release</pre>
<p>The <code>-Papache-release</code> is used to have the build mimic the
build actions that would be taken when the release plugin is running
the release build.</p>
@@ -646,7 +645,7 @@ mvn install -Papache-release</pre>
several multi-megabyte zip/tar files, these will just waste space in SVN.
</p>
<p>
- The alternative is to stage the release candidate in your personal people.apache.org/~[user-id] space, and
+ The alternative is to copy the release candidate for voting into your personal people.apache.org/~[user-id] space, and
let testers/voters pull it from there.
</p>
<p>If you do use the distribution SVN for the release candidates,
@@ -694,13 +693,11 @@ mvn install -Papache-release</pre>
<p>
The actual creation of the update site is done in several steps, following
the conventions to
- <a href="saving-svn-resources.html">save SVN resources</a>. First, SVN copy (if needed)
- the existing released composite update site
- (from https://dist.apache.org/repos/dist/release/uima/eclipse-update-site) to
- https://dist.apache.org/repos/dist/dev/uima/eclispe-update-site (the staging spot for releases).
- Next, check out the existing update site from the dev spot into a working directory
- Next, update the working directory with any changes, and then check it back in (to the /dev/... spot).
- Note that any JARs, Zips, Tars, tar.gz artifacts need to be signed.
+ <a href="saving-svn-resources.html">save SVN resources</a>.
+ The Maven build for Eclipse update sites
+ will end up with files in .../target/eclipse-update-site/[subsite] which
+ should be copied to some accessible spot for Voting/ testing.
+ (After the vot passes, the files in the target site can be svn switched to the release directory and committed.)
</p>
<p>Test the result: using the extended composite repository in various versions of
Eclipse, and verify it installs OK.
@@ -772,10 +769,8 @@ mvn install -Papache-release</pre>
<li>Promote the release(s) from the staging repositories:
log on to the staging repository again, and release the staged artifacts.
This will make the artifacts available in the Maven Central repository.</li>
- <li><p>If the release candidate used the distribution (...dev/uima) spot,
- SVN move the release artifacts from the distribution SVN staging spot
- in dev/uima to release/uima. Otherwise, log on to people.a.o and do
- SVN add of the voted-on artifacts from the place where they were staged.
+ <li><p>Do an svn add of the new released artifacts (bin.tar/zip) to the
+ Apache release svn.
</p>
<!--
@@ -783,7 +778,9 @@ mvn install -Papache-release</pre>
the existing previous plugin releases already on the update site).
-->
<p>
- If Eclipse plugins are being released, promote any changed files to the release/uima directory.
+ If Eclipse plugins are being released,
+ do an svn switch to switch the files being released from the .../dev/...
+ to the .../release/... directory in dist.apache.org.
</p>
<p>
Make sure the KEYS file in release/uima is current (master located in
Modified: uima/site/trunk/uima-website/xdocs/checklist-release.xml
URL: http://svn.apache.org/viewvc/uima/site/trunk/uima-website/xdocs/checklist-release.xml?rev=1510683&r1=1510682&r2=1510683&view=diff
==============================================================================
--- uima/site/trunk/uima-website/xdocs/checklist-release.xml (original)
+++ uima/site/trunk/uima-website/xdocs/checklist-release.xml Mon Aug 5 19:39:57 2013
@@ -32,6 +32,19 @@ under the License.
<li>Do <a href="one-time-release-setup.html">one-time setup</a> required for releasing.</li>
<li>Finish up any changes, close Jiras, assign Jiras to proper release(s).</li>
<li>Update the READMEs and RELEASE-NOTES.</li>
+ <li>Make a new build directory for this release, and svn export the trunk. This is so you can
+ preserve the build for later upload of selected artifacts to the distribution spot.
+ If instead you are building from an existing checkout, do a svn update to be sure the workspace is up-to-date.</li>
+ <li>Purge your local maven repository of artifacts being built by running in the
+ top level directory you'll be building from:
+ <br/><br/>
+ <code>mvn dependency:purge-local-repository</code><br/><br/>
+ Note that this will immediately re-resolve the dependencies from the maven repositories
+ you have configured.
+ </li>
+ <li>Try a full build: mvn deploy</li>
+ <li>If retrying a release candidate, delete the old rc-xxx in svn xxx/tags/</li>
+ <li>If retrying a release candidate, <code><b>close</b></code> (and <code><b>drop</b></code> as appropriate) any previous repository.apache.org staging repo</li>
<!--li>(If remerging a branch: Note- best to do these if possible at the root of aggregations,
outside of Eclipse, so svn "batching" can work - will be quite a bit fraster)
<ol><li>update branch working copy to head</li>
@@ -46,8 +59,7 @@ under the License.
<p>More details on next steps are
<a href="http://maven.apache.org/developers/release/apache-release.html">here</a></p>
<ol>
- <p>Make sure you've not left open a previous release candidate staging repository.
- Then release one or more artifacts into the Apache Nexus staging repository.
+ <p>Release one or more artifacts into the Apache Nexus staging repository.
You can do multiple release:prepare/perform steps, with subsequent steps
depending on the previous artifacts in their "release" version.</p>
<li>Do next steps in top release artifact (single module, or mult-module top project).
@@ -59,7 +71,6 @@ under the License.
For multi-module projects, where all the submodules have the same version, use: <br/>
<code>mvn release:prepare -DdryRun -DautoVersionSubmodules</code>.
<li><code>mvn release:clean</code> to restore projects</li>
- <li><code>mvn deploy</code> to deploy snapshot</li>
<li><code>mvn release:prepare [-DautoVersionSubmodules]</code>.
Try to accept the default suggestions for names; you might change the SVN tag to include a "-rc1"
suffix indicating a release candidate number.</li>
@@ -80,6 +91,9 @@ under the License.
depend on the release version of previous steps. When you're done, you will have 1 or more
"closed" staging repositories, each having a unique URL.
</li-->
+ <li>If necessary, run mvn release:prepare on the eclipse update site. This will create the svn tag,
+ and create the needed artifacts in the target/eclipse-update-site.
+ No need to run release:perform because no artifacts from this are going to Maven central distribution.</li>
<li>Copy any artifacts (together with their signings) to the staging spot. This is typically
in your people.apache.org/~[userid]/public_html directory. For releases which include eclipse-update-site
packagings, this should include any modifications to the composite update site or subsites (see
@@ -88,11 +102,17 @@ under the License.
<li>Send [VOTE] message to dev list. List the staging repository that testers
will need to add to their <code>settings.xml</code> files, and the distribution SVN repo link.</li>
<li>Post RESULT message</li>
- <li>Delete any artifacts from the staging repo that aren't supposed to go to Maven Central
- (currently only the bin.tar artifacts - the bin.zip is used for building uima-as)</li>
+ <li>Delete any artifacts from the staging repo that aren't supposed to go to Maven Central (if any).
+ The uimaj build doesn't put the bin.zip or bin.tar artifacts on the staging repo, but
+ other builds might need some cleanup.
+ </li>
<li>Promote the release(s) from the staging repositories</li>
- <li>Add the approved staged artifacts to the release/uima spot: log onto people.a.o and do an svn add
- of the actual staged signed artifacts.</li>
+ <li>Add the approved staged artifacts to the release/uima spot.
+ Do an svn add on the bin (zip and tar) and source-release files and their sigs.
+ Do not add files like POMs which have line-endings, if they have signatures; the files added should
+ be "binary" style files. (The line endings (if you build on windows) will be changed upon upload to svn,
+ which will result in bad signatures).
+ </li>
<li>update the UIMA website docs/d with any generated docs, in a manner to
<a href="saving-svn-resources.html">minimize SVN space</a> use, if possible.
This includes: PDFs, HTML versions of docbooks plus the index.html; all go on the
Modified: uima/site/trunk/uima-website/xdocs/release.xml
URL: http://svn.apache.org/viewvc/uima/site/trunk/uima-website/xdocs/release.xml?rev=1510683&r1=1510682&r2=1510683&view=diff
==============================================================================
--- uima/site/trunk/uima-website/xdocs/release.xml (original)
+++ uima/site/trunk/uima-website/xdocs/release.xml Mon Aug 5 19:39:57 2013
@@ -166,8 +166,7 @@ A previous version of this page, with th
<subsection name="Including updates to the Build tooling">
<p>This step is skipped, unless the build tooling is being updated.</p>
- <p>There are two projects in the build tooling, each having as a parent, the common Apache Parent POM
- <b>uima-build-resources</b> and <b>parent-pom</b>.
+ <p>There are several projects in the build tooling.
The following special procedure is used to release updates to these.
</p>
<p>
@@ -199,7 +198,7 @@ A previous version of this page, with th
NEXUS staging repository.
</p>
- <p>During this process, the release plugin asks what the next levels should be and what the tag name
+ <p>During release:prepare, the release plugin asks what the next levels should be and what the tag name
should be, and unless there's a good reason, we take the defaults (by just hitting enter).
The exception to this is in naming the SVN TAG - normally we have "release candidates".
The recommended convention is to take the suggested name and add "-rc1" for release candidate 1,
@@ -208,7 +207,7 @@ A previous version of this page, with th
<p>The release plugin automatically signs everything that needs signing using gpg. It also
builds the sources.jar, and one overall (for multi-module projects) source-release.zip file,
which can be later obtained and
- should be a copy of the SVN tag for that artifact, and once unzipped, should be buildable,
+ should be an (approximate) copy of the SVN tag for that artifact, and once unzipped, should be buildable,
using <code>mvn install</code>.
</p>
@@ -227,7 +226,7 @@ A previous version of this page, with th
<li>
Do a trial build of the release candidate:
<pre>cd **directory for doing the release**
-mvn install -Papache-release</pre>
+ mvn deploy -Papache-release</pre>
<p>The <code>-Papache-release</code> is used to have the build mimic the
build actions that would be taken when the release plugin is running
the release build.</p>
@@ -351,7 +350,7 @@ mvn install -Papache-release</pre>
several multi-megabyte zip/tar files, these will just waste space in SVN.
</p>
<p>
- The alternative is to stage the release candidate in your personal people.apache.org/~[user-id] space, and
+ The alternative is to copy the release candidate for voting into your personal people.apache.org/~[user-id] space, and
let testers/voters pull it from there.
</p>
@@ -430,13 +429,11 @@ mvn install -Papache-release</pre>
<p>
The actual creation of the update site is done in several steps, following
the conventions to
- <a href="saving-svn-resources.html">save SVN resources</a>. First, SVN copy (if needed)
- the existing released composite update site
- (from https://dist.apache.org/repos/dist/release/uima/eclipse-update-site) to
- https://dist.apache.org/repos/dist/dev/uima/eclispe-update-site (the staging spot for releases).
- Next, check out the existing update site from the dev spot into a working directory
- Next, update the working directory with any changes, and then check it back in (to the /dev/... spot).
- Note that any JARs, Zips, Tars, tar.gz artifacts need to be signed.
+ <a href="saving-svn-resources.html">save SVN resources</a>.
+ The Maven build for Eclipse update sites
+ will end up with files in .../target/eclipse-update-site/[subsite] which
+ should be copied to some accessible spot for Voting/ testing.
+ (After the vot passes, the files in the target site can be svn switched to the release directory and committed.)
</p>
<p>Test the result: using the extended composite repository in various versions of
@@ -486,10 +483,8 @@ mvn install -Papache-release</pre>
<li>Promote the release(s) from the staging repositories:
log on to the staging repository again, and release the staged artifacts.
This will make the artifacts available in the Maven Central repository.</li>
- <li><p>If the release candidate used the distribution (...dev/uima) spot,
- SVN move the release artifacts from the distribution SVN staging spot
- in dev/uima to release/uima. Otherwise, log on to people.a.o and do
- SVN add of the voted-on artifacts from the place where they were staged.
+ <li><p>Do an svn add of the new released artifacts (bin.tar/zip) to the
+ Apache release svn.
</p>
<!--
@@ -497,7 +492,9 @@ mvn install -Papache-release</pre>
the existing previous plugin releases already on the update site).
-->
<p>
- If Eclipse plugins are being released, promote any changed files to the release/uima directory.
+ If Eclipse plugins are being released,
+ do an svn switch to switch the files being released from the .../dev/...
+ to the .../release/... directory in dist.apache.org.
</p>
<p>
Make sure the KEYS file in release/uima is current (master located in