Google Git
Sign in
apache / uima-site / ae4bf94d1ce1ffde6303a4333f17c60c9898a0a9 / . / docs / release.html
blob: c974ee132252110241692043e63eaa4f8c37ab0f [file] [log] [blame]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "https://www.w3.org/TR/html4/loose.dtd">
<!-- ====================================================================== -->
<!-- GENERATED FILE, DO NOT EDIT, EDIT THE XML FILE IN xdocs INSTEAD! -->
<!-- ====================================================================== -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
<style type="text/css">@import "stylesheets/base.css";</style>
<meta name="author" value="Apache UIMA Documentation Team">
<meta name="email" value="dev@uima.apache.org">
<title>Apache UIMA - Doing an Apache UIMA Release</title>
<!-- Begin Cookie Consent plugin by Silktide - https://silktide.com/cookieconsent -->
<!-- Commented out because implied consent is not compatible with GDPR -->
<!--
<script type="text/javascript">
window.cookieconsent_options = {"message":"This website uses cookies to ensure you get the best experience on our website","dismiss":"Got it!","learnMore":"More info","link":"https://uima.apache.org/privacy-policy.html","theme":"dark-bottom"};
</script>
<script type="text/javascript" src="/cookieconsent2/cookieconsent.min.js"></script>
-->
<!-- End Cookie Consent plugin -->
<!-- Begin Google Analytics -->
<!-- Commented out because GA requires consent according to GDPR -->
<!--
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-70846351-1', 'auto');
ga('set', 'anonymizeIp', true);
ga('send', 'pageview');
</script>
-->
<!-- End Google Analytics -->
</head>
<body>
<div class="topLogos">
<table border="0" width="100%" cellspacing="0">
<!-- TOP IMAGE -->
<tr>
<td align='LEFT'>
<a href="index.html">
<img style="border: 1px solid black;" src="./images/UIMA_banner2tlpTm.png" alt="UIMA project logo" border="0"/>
</a>
</td>
<td align='CENTER'>
<div class="pageBanner">Doing an Apache UIMA Release</div>
</td>
<td align='RIGHT'>
<a href="https://www.apache.org">
<img src="./images/asf-logo-on-white-smallTm.png" alt="Apache UIMA" border="0"/>
</a>
</td>
</tr>
</table>
<hr noshade="" size="1"/>
</div>
<table border="0" width="100%" cellspacing="4">
<tr>
<td align='RIGHT' colspan="2">
<form method="get" action="https://www.google.com/search">
Search the site
<input type="text" name="q" size="25" maxlength="255" value="" />
<input type="hidden" name="sitesearch" value="https://uima.apache.org/" />
<input name="Search" value="Search Site" type="submit"/>
</form>
</td>
</tr>
<tr> <!-- LEFT SIDE NAVIGATION -->
<td width="20%" valign="top">
<!-- regular menu -->
<div class="navBar">
<br/>
<div class="navBarItem"> <div class="navPartHeading">General</div>
</div>
<div class="navBar">
<div class="navBarItem"> <a href="./index.html">Home</a>
</div>
<div class="navBarItem"> <a href="./downloads.cgi">Downloads</a>
</div>
<div class="navBarItem"> <a href="./documentation.html">Documentation</a>
</div>
<div class="navBarItem"> <a href="./news.html">News</a>
</div>
<div class="navBarItem"> <a href="./publications.html">Publications</a>
</div>
<br style="line-height: .5em"/>
<div class="navBarItem"> <a href="https://issues.apache.org/jira/browse/uima" target="_blank" rel="noopener">Issue tracker <img src="images/offsitelink.png"/></a>
</div>
<div class="navBarItem"> <a href="https://cwiki.apache.org/confluence/display/UIMA/" target="_blank" rel="noopener">Wiki <img src="images/offsitelink.png"/></a>
</div>
<br style="line-height: .5em"/>
<div class="navBarItem"> <a href="https://cwiki.apache.org/confluence/display/UIMA/Powered+by+Apache+UIMA" target="_blank" rel="noopener">Powered By UIMA <img src="images/offsitelink.png"/></a>
</div>
</div>
<br/>
<div class="navBarItem"> <div class="navPartHeading">Community</div>
</div>
<div class="navBar">
<div class="navBarItem"> <a href="./get-involved.html">Get Involved</a>
</div>
<div class="navBarItem"> <a href="./mail-lists.html">Mailing Lists</a>
</div>
<div class="navBarItem"> <a href="./contribution-policy.html">Contribution Policies</a>
</div>
<div class="navBarItem"> <a href="./faq.html">FAQ</a>
</div>
<div class="navBarItem"> <a href="./project-guidelines.html">Project Guidelines</a>
</div>
</div>
<br/>
<div class="navBarItem"> <div class="navPartHeading">Scaleout Frameworks</div>
</div>
<div class="navBar">
<div class="navBarItem"> <a href="./doc-uimaas-what.html">UIMA-AS</a>
</div>
<div class="navBarItem"> <a href="./doc-uimaducc-whatitam.html">UIMA-DUCC</a>
</div>
<div class="navBarItem"> <a href="./doc-uimaducc-demo.html">..Demo Page</a>
</div>
<div class="navBarItem"> <a href="http://uima-ducc-demo.apache.org:42133" target="_blank" rel="noopener">..Demo Live <img src="images/offsitelink.png"/></a>
</div>
</div>
<br/>
<div class="navBarItem"> <div class="navPartHeading">Components & Tools</div>
</div>
<div class="navBar">
<div class="navBarItem"> <a href="./sandbox.html#uima-addons-annotators">Annotators</a>
</div>
<div class="navBarItem"> <a href="./toolsServers.html">Tools & Servers</a>
</div>
<div class="navBarItem"> <a href="./sandbox.html">Addons and Sandbox</a>
</div>
<div class="navBarItem"> <a href="./ruta.html">UIMA Ruta</a>
</div>
<div class="navBarItem"> <a href="./uimafit.html">uimaFIT</a>
</div>
<div class="navBarItem"> <a href="./external-resources.html">External Resources</a>
</div>
</div>
<br/>
<div class="navBarItem"> <div class="navPartHeading">Development</div>
</div>
<div class="navBar">
<div class="navBarItem"> <a href="./dev-quick.html">Quick Start: building</a>
</div>
<div class="navBarItem"> <a href="./building-uima.html">Building from Source</a>
</div>
<div class="navBarItem"> <a href="./one-time-setup.html">One-time setups</a>
</div>
<div class="navBarItem"> <a href="./svn.html">Source Code</a>
</div>
<div class="navBarItem"> <a href="./release.html">Doing a UIMA release</a>
</div>
<div class="navBarItem"> <a href="https://www.apache.org/security/committers.html" target="_blank" rel="noopener">Doing a CVE (Apache) <img src="images/offsitelink.png"/></a>
</div>
<div class="navBarItem"> <a href="./eclipse-update-site.html">Eclipse Update Sites</a>
</div>
<div class="navBarItem"> <a href="./git.html">GIT</a>
</div>
<div class="navBarItem"> <a href="./codeConventions.html">Code Conventions</a>
</div>
<div class="navBarItem"> <a href="./uima-specification.html">UIMA Specification (OASIS)</a>
</div>
<div class="navBarItem"> <a href="./team-list.html">Project Team</a>
</div>
<div class="navBarItem"> <a href="./maven-design.html">Maven Use</a>
</div>
<div class="navBarItem"> <a href="./updating-website.html">Updating this Website</a>
</div>
</div>
<br/>
<div class="navBarItem"> <div class="navPartHeading">Events and Conferences</div>
</div>
<div class="navBar">
<div class="navBarItem"> <a href="./coling14.html">COLING 2014</a>
</div>
<div class="navBarItem"> <a href="./gscl13.html">GSCL 2013</a>
</div>
<div class="navBarItem"> <a href="./iks09.html">IKS 2009</a>
</div>
<div class="navBarItem"> <a href="./gscl09.html">GSCL 2009</a>
</div>
<div class="navBarItem"> <a href="./lsm09.html">LSM 2009</a>
</div>
<div class="navBarItem"> <a href="./lrec08.html">LREC 2008</a>
</div>
<div class="navBarItem"> <a href="./gldv07.html">GLDV 2007</a>
</div>
</div>
<br/>
<div class="navBarItem"> <div class="navPartHeading">ASF</div>
</div>
<div class="navBar">
<div class="navBarItem"> <a href="https://www.apache.org/licenses/" target="_blank" rel="noopener">License <img src="images/offsitelink.png"/></a>
</div>
<div class="navBarItem"> <a href="https://www.apache.org/foundation/thanks.html" target="_blank" rel="noopener">ASF Sponsors <img src="images/offsitelink.png"/></a>
</div>
<div class="navBarItem"> <a href="https://www.apache.org/foundation/sponsorship.html" target="_blank" rel="noopener">ASF Sponsorship <img src="images/offsitelink.png"/></a>
</div>
<div class="navBarItem"> <a href="./security_report">Security</a>
</div>
</div>
</div>
</td>
<td width="80%" align="left" valign="top">
<div class="sectionTable">
<table class="sectionTable">
<tr><td>
<a name="Doing an Apache UIMA&trade; Release"><h1><img src="images/UIMA_4sq50tightCropSolid.png"/>&nbsp;Doing an Apache UIMA&trade; Release</h1></a>
</td></tr>
<tr><td>
<blockquote class="sectionBody">
<p class="note">These instructions are for the 2.3.1 and later releases, as a top level project.
A previous version of this page, with the methods we used while in the incubator, is
<a href="release-before-2.3.1.html">here</a>.
</p>
<p>Once you've done it a few times, you may find the shorter
<a href="checklist-release.html">release checklist</a> more convenient.
</p>
<ul>
<li><a href='#Release Overview'>
Release Overview
</a></li>
<li><a href='#Release Discussions - Release Plan'>
Release Discussions - Release Plan
</a></li>
<li><a href='#Preparing the Jira for the Release'>
Preparing the Jira for the Release
</a></li>
<li><a href='#Preparing The Sourcecode For The Release'>
Preparing The Sourcecode For The Release
</a></li>
<li><a href='#Including updates to the Build tooling'>
Including updates to the Build tooling
</a></li>
<li><a href='#Building The Release Candidate'>
Building The Release Candidate
</a></li>
<li><a href='#Tips for the Release Manager'>
Tips for the Release Manager
</a></li>
<li><a href='#Removing -SNAPSHOT dependencies'>
Removing -SNAPSHOT dependencies
</a></li>
<li><a href='#Copying release artifacts to staging spot'>
Copying release artifacts to staging spot
</a></li>
<li><a href='#Stage the eclipse-update-site'>
Stage the eclipse-update-site
</a></li>
<li><a href='#Doing The Release Vote'>
Doing The Release Vote
</a></li>
<li><a href='#Releasing'>
Releasing
</a></li>
<li><a href='#Announce The Release'>
Announce The Release
</a></li>
</ul>
<br />
<table class="subsectionTable">
<tr><td>
<a name="Release Overview">
<h2>Release Overview
</h2>
</a>
</td></tr>
<tr><td>
<blockquote class="subsectionBody">
<p>
The UIMA project mainly releases:
<ul><li>The UIMA SDK</li>
<li>UIMA-AS add-on</li>
<li>UIMA-CPP</li>
<li>uimaFIT</li>
<li>RUTA</li>
<li>DUCC</li>
<li>Individual Annotators, tooling, and other useful components (like the Simple Server)</li></ul>
In addition, it releases some Maven build tooling components that
need to be in the Maven repositories to support our Maven processes.
</p>
<p>
Releases show up in the Maven central repository and/or
as downloadable artifacts listed on our downloads pages.
</p>
</blockquote>
</td></tr>
</table>
<table class="subsectionTable">
<tr><td>
<a name="Release Discussions - Release Plan">
<h2>Release Discussions - Release Plan
</h2>
</a>
</td></tr>
<tr><td>
<blockquote class="subsectionBody">
<p>
At the beginning of the "UIMA Release Process" there must be consensus in the developer community
about the JIRA issues that should be part of the next release and the time frame for the release.
(Optional) The result of this discussion should be published in a release plan to the UIMA wiki, if it is
complex.
This release plan should be kept up-to-date any time so that everybody can have a look at the target dates
to calculate personal ToDos.
</p>
<p>
The previous UIMA release plans and a release plan template are available in the UIMA wiki at
<a href="https://cwiki.apache.org/confluence/display/UIMA/release-plan.html">https://cwiki.apache.org/confluence/display/UIMA/release-plan.html</a>
</p>
</blockquote>
</td></tr>
</table>
<table class="subsectionTable">
<tr><td>
<a name="Preparing the Jira for the Release">
<h2>Preparing the Jira for the Release
</h2>
</a>
</td></tr>
<tr><td>
<blockquote class="subsectionBody">
<p>
The build includes a generated set of Jira issues fixed (closed or resolved) in this release.
To make this accurate, go through the Jiras and ensure the ones you are including in the release
are closed/resolved, and that the "Fixed in release xxx" is set for each Jira issue that is part of the
release.
</p>
<p>
There is a saved "filter" you can adjust for this that will display all fixed Jira issues with no Fixed in release xxx
assigned. You can go through subsets of this (use the filter to pick the subset you want)
and do "bulk Jira changes" to update multiples of these in parallel, if that makes sense.
</p>
</blockquote>
</td></tr>
</table>
<table class="subsectionTable">
<tr><td>
<a name="Preparing The Sourcecode For The Release">
<h2>Preparing The Sourcecode For The Release
</h2>
</a>
</td></tr>
<tr><td>
<blockquote class="subsectionBody">
<p>
Before the source code can be tagged for the release check the points in the list below:
</p>
<p>
<ul>
<li>Investigate versions of things using <br /><br />
<code>mvn versions:display-dependency-updates<br />
mvn versions:display-plugin-updates and<br />
mvn versions:display-property-updates</code><br /><br />
Use this information to update to later versions, if appropriate.</li>
<li>
Make sure that each release artifact that should be released has the correct version number.
These are normally updated automatically when the previous release is done.
<!--
There is an ant build script you can run here: <code>uimaj-distr/src/main/build/changeVersion.xml</code>.
To run it, first edit the file versions.properties in the same ... / build directory, setting
the "previous" version (the current version info in the source), and the "new" version that it
should be set to. Then, <code>cd</code>
to <code>uimaj-distr/src/main/build</code> and do <code>ant changeVersion.xml</code> to run it.
It checks the following places for correct versions.
<ul>
<li>uimaj project: POM.xml</li>
<li>uimaj child projects: check version for the parent POM</li>
<li>uimaj plugin projects (uimaj-ep-...): MANIFEST.MF</li>
<li>uimaj-core project: UIMAFramework_impl.java</li>
<li>uimaj-dist project: ReleaseNotes and Readme files</li>
<li>uima-docbooks project: common_book_info.xml and index.html</li>
<li>uimaj Eclipse features</li>
</ul>
Some of these things it doesn't update (if the update is complicated); in these case,
it will instead, issue a reminder message to you
to update things manually. -->
</li>
<li>
Make sure that any README files have been updated with the latest release information
and release numbers.
</li>
<li>
Update the release notes for the release.
<!-- JIRA can provide a list of
issues for a certain release when using the 'ReleaseNotes' function,
after you've closed the Jira issues to be released with this version. -->
</li>
<li>Edit the POM of the top level thing being released, to add the property:
<pre>&lt;jiraVersion&gt;2.10.2SDK&lt;/jiraVersion&gt;</pre>
replacing the 2.10.2SDK with the actual Jira version name for the Jira release being
done. This value is used during release processing to automatically
generate a report of the list of Jira issues that are included in this release.
Change "2.10.2SDK"" to be the actual jira version name, which you can get
from the Jira url
by going to https://issues.apache.org/jira/browse/UIMA
and selecting "Releases" and then going to the
particular version and copying its name.
<p>
You can also generate this report manually (for instance, if you want to
have a look at what it will produce) by going to top level project
being released (e.g., uimaj-distr) and issuing the maven command:
<pre>mvn changes:jira-report -N </pre></p>
<p>Each time this plugin is run, it creates an updated report in the
top level of this project. This report doesn't need to be checked into source control.
It will be regenerated and copied into the distribution archives (source and binary)
during a release. The RELEASE_NOTES.html files have been updated to
refer to this generated report.</p>
<p>Running the mvn release... command will cause this report to be generated or
updated, every time the command is run. So it is important that the POM
is updated to include the internal Jira version number, so the
right report is generated.</p>
</li>
<li><b>NEW !!! </b>Update the parent-pom settings for API change reports setting
api_check_old_version to the correct previous version to use.</li>
</ul>
</p>
</blockquote>
</td></tr>
</table>
<table class="subsectionTable">
<tr><td>
<a name="Including updates to the Build tooling">
<h2>Including updates to the Build tooling
</h2>
</a>
</td></tr>
<tr><td>
<blockquote class="subsectionBody">
<p>This step is skipped, unless the build tooling is being updated.</p>
<p>There are several projects in the build tooling.
The following special procedure is used to release updates to these.
</p>
<p>
The parent-pom has the uima-build-resources's version number encoded as the
"property" <pre>&lt;uimaBuildResourcesVersion&gt;XXXXXX&lt;/uimaBuildResourcesVersion&gt;</pre>
This value will normally be set to the last released version number of the uima-build-resources artifact.
</p>
<p>If that artifact is changing, during development, this will be set to the XX-SNAPSHOT value corresponding to
the development version. When releasing, first do a release (to the Nexus Staging repository, as usual) of
the uima-build-resources artifact, which will create a version without the -SNAPSHOT. Then change the
&lt;uimaBuildResourcesVersion&gt; value to correspond to the non-SNAPSHOT version number of this, before
proceeding to release the parent-pom artifact.</p>
</blockquote>
</td></tr>
</table>
<table class="subsectionTable">
<tr><td>
<a name="Building The Release Candidate">
<h2>Building The Release Candidate
</h2>
</a>
</td></tr>
<tr><td>
<blockquote class="subsectionBody">
<p class="note">Prior to releasing, you must do the
<a href="one-time-release-setup.html">one-time setup</a>
required for releasing. Be sure to use the correct Java level (e.g. 1.7, 1.8, etc.), in order to catch
accidental dependencies on later Java features.
</p>
<p>
We use the maven-release-plugin to do the releasing. In the prepare phase, it updates the
trunk artifacts to remove the -SNAPSHOT suffix, commits it to trunk, and then does an
SVN copy or GIT Branch of the trunk or master to create the tag. Then it updates the trunk artifacts to the next
version-SNAPSHOT, and commits that.
</p>
<p>The release:perform checks out the tag and builds/tests/installs and deploys it to the
NEXUS staging repository.
</p>
<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).
</p>
<p class="note">In the past, we added a suffix representing the release candidate to the tag,
e.g. "-rc1" for release candidate 1, etc. However, the URL for this tag becomes part
of the released POM. After a successful vote, we would have upgraded the release candidate to
the final release by renaming the tag in source control. At that point, the URL in the
POM would have become invalid. For this reason, it was decided not to add the -rc1 to the
tag anymore.
</p>
<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 an (approximate) copy of the tag for that artifact, and once unzipped, should be buildable,
using <code>mvn install</code>.
</p>
<p>Steps:
<ul>
<li>Make sure all changes are checked into source control. Then checkout (not export) from source control the project(s)
you'll be building, into a new "build" location, and do all the building from there.</li>
<li>If you instead choose to build from your "working" source control checkout, insure it's up-to-date with
all changes that others may have checked into trunk.</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.
<p>For many multi-module projects, this will fail because it purges things that other modules need.
So, the alternative is to just delete the .m2/.../uima/... directory on your build machine.</p>
</li>
<li>
Do a trial build of the release candidate:
<pre>cd **directory for doing the release**
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>
</li>
<li><code>mvn release:prepare -DautoVersionSubmodules</code></li>
<li><code>mvn release:perform</code></li>
</ul>
</p>
<p>Normally, everything built is uploaded to the Apache's Nexus Staging repository. However, for the
(large) distribution objects, such as the source and binary distributions for UIMA Java SDK etc.,
the "deploy" step is skipped. These artifacts, instead of being "distributed" using the
Maven central repository, are distributed using the Apache Mirroring System.</p>
<p>You can upload to the Nexus Staging repository several independent artifacts; they will
all get added to the same unique temporary staging repository Nexus creates. Once all the
artifacts are in place, you log into
<a target="_blank" rel="noopener" href="https://repository.apache.org">https://repository.apache.org</a> using your
LDAP credentials, go to your staging repository, and "close" the repository. After that,
nothing more can be added. If you deploy another artifact, it will create a new
staging repository.</p>
<p class="note"><b>If you forget to close the repo</b>, it will be open when you do your next
release candidate, and then you'll have in the repo both release candidates, (with
later files overwriting newer), which if any file names have changed, will <b>create
a mess. So be sure to <code><b>close</b></code> (and <code><b>drop</b></code> as appropriate) any previous repo</b> before starting a release:perform for a new
release candidate, so they deploy into a "fresh" empty staging repo.</p>
<p>If you have several artifacts to release, and you want subsequent artifacts to
depend on the released versions of earlier ones, you can do this, by releasing the
first one, then releasing subsequent ones that depend on that, etc. This works because
the first one you release will get built with the release version and installed to your
local repository, as well as the Nexus staging repository. So subsequent ones that depend on
the release version of previous ones, will find that in your local repository.
</p>
<p>
If you forget something and close the staging repository too soon, just continue as if you hadn't.
Subsequent release artifacts will go into another newly created staging spot on Nexus.
The downside of this is that you'll have to tell the "voters" about multiple staging repos.
</p>
</blockquote>
</td></tr>
</table>
<table class="subsectionTable">
<tr><td>
<a name="Tips for the Release Manager">
<h2>Tips for the Release Manager
</h2>
</a>
</td></tr>
<tr><td>
<blockquote class="subsectionBody">
<p>
The release is done using the commands <code>mvn release:prepare</code> and <code>mvn release:perform</code>.
</p>
<p><b><u>Having all submodules at the same version:</u></b>
When releasing a multi-module project where all the submodules have the same release version as the
root project (e.g., uimaj-distr), you can have the release plugin set the version for all the submodules
the same value as the root, automatically, just use this form of the release:prepare:
<pre>mvn release:prepare -DautoVersionSubmodules</pre>
</p>
<p>
<b><u>Trying out the release build:</u></b> You can build the artifacts that the release would build by using:
<pre>mvn package -Papache-release</pre>
</p>
<p>
<b><u>Re-doing release candidates:</u></b> There are two ways to reset things back so you can do
another release candidate; depending on how far through the release process you've progressed.
</p>
<p style="margin-left:3em"><code>[mvn release:prepare]</code> If you've just done release:prepare,
you can reset things back to as they were before that command by issuing
<code>mvn release:rollback</code>. Check to confirm that the source control tag for the
release candidate is deleted; if not, remove it manually.
</p>
<p style="margin-left:3em"><code>[mvn release:perform]</code> If you've done a release:perform, to
reset the source, try doing the release:rollback; this may work if you haven't done a release:clean.
</p>
<p style="margin-left:3em">Otherwise,
you have to change the &lt;version&gt;x.y.z-SNAPSHOT&gt; back to their previous value.
You can use Eclipse's search/replace to do this, or the mvn versions plugin.
</p>
<p style="margin-left:3em">If you've
"closed" the Nexus repo - you have to drop it. If you haven't, you can just re-run the
release:perform when you're ready, and that will overwrite the staging repo data in Nexus. But see
the next tip.
</p>
<p>
<b><u>Nexus staging repositories and your source computer</u></b> The staging repo that
receives the output of <code>mvn release:perform</code> has as part of its name, the
IP address where the deploy comes from. If you have a laptop, and do part of the release
at "work", and then another part at "home", the IP address will be different, and
multiple staging repositories will be created. This is not a problem, usually, unless
you are <i>updating</i> a release by redoing it, and are expecting the previous version
to be overwritten. In case it isn't, you can just use the Nexus command line interface
to delete the old version from the "other" staging repo.
</p>
</blockquote>
</td></tr>
</table>
<table class="subsectionTable">
<tr><td>
<a name="Removing -SNAPSHOT dependencies">
<h2>Removing -SNAPSHOT dependencies
</h2>
</a>
</td></tr>
<tr><td>
<blockquote class="subsectionBody">
<p>
POMs can refer to other artifacts in several ways, for example via the &lt;parent-pom&gt;
element, or via a &lt;dependency&gt; element. Often, a release will involve releasing together
multiple modules (all at -SNAPSHOT levels) that refer to one another using these elements.
When that happens, the references in these two elements are automatically updated
during the release process, from xx-SNAPSHOT to xx for the tag, and then to the next development level,
for the trunk.
</p>
<p>Exception to this: -SNAPSHOT suffixes are not updated for references within plugins.</p>
</blockquote>
</td></tr>
</table>
<table class="subsectionTable">
<tr><td>
<a name="Copying release artifacts to staging spot">
<h2>Copying release artifacts to staging spot
</h2>
</a>
</td></tr>
<tr><td>
<blockquote class="subsectionBody">
<p>
Note that any JARs, Zips, Tars, tar.gz artifacts must be signed by the Release Manager.
</p>
<p>
We have a spot in the distribution SVN under dev/uima for all the artifacts to be released
via the Apache mirror system. This is where you put the
release candidates.
</p>
<p>Be sure to copy artifacts from the build-from tag spot, which should have a path like:
...[top level project]/target/checkout/target. Note this is not from [top level project]/target.
Doing this will guarantee that you're posting the artifacts built from the tag (which could be
different from the release:prepare build in /target if someone snuck in a svn commit at the right moment.)</p>
<p>Copy any artifacts (together with their signings) to the staging spot.
A suggested approach: Make a new dir in the build project, called svnUpload (or whatever), and
copy the artifacts (<b>from the build/target/checkout/target directory</b>)(typically the
bin/zip/tar and the source release and all the signature/checksums) into this dir. Then do the svn command:
<pre>cd the-svnUpload-directory
svn import -m "commit msg, e.g. uimaj-2.8.0 rc5" . https://dist.apache.org/repos/dist/dev/uima/uimaj/n.n.n-rc1/artifacts
</pre></p>
</blockquote>
</td></tr>
</table>
<table class="subsectionTable">
<tr><td>
<a name="Stage the eclipse-update-site">
<h2>Stage the eclipse-update-site
</h2>
</a>
</td></tr>
<tr><td>
<blockquote class="subsectionBody">
<p>For a general background on how we build P2 sites, including Composite
update sites, see <a href="eclipse-update-site.html">eclipse-update-site</a> page.
</p>
<p>
The component being released, if it has Eclipse features, will have its own
Eclipse update (sub) site, which should be built along with the normal build of
the entire component, as part of that component's release.
</p>
<p>
In building that component's update site, you may need to edit/update the affected
component's feature project(s), and the category.xml file in the update-site, before
building it. For releases, run the signEclipseUpdateSite.sh (on Windows - inside Cygwin)
to sign the Jars. (Optional:) There's also a verifySignsEclipseUpdateSite.sh you can run to verify
the signing was successful.
</p>
<p>
If a new Eclipse update site is being added to the composite, edit in the composite
project (.../build/uima-eclipse-composite-update-site) the buildCompositeRepository.xml
file to add the new update site. If doing a release, run the signing script for the
composite site too.
</p>
<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>.
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.
</p>
<p>
If you changed the composite site, bump up the version of .../build/uima-eclipse-composite-site/pom.xml
and commit project changes to the trunk, and tag it.
The component's individual update sites should be built and tagged as part of that project's release.
</p>
</blockquote>
</td></tr>
</table>
<table class="subsectionTable">
<tr><td>
<a name="Doing The Release Vote">
<h2>Doing The Release Vote
</h2>
</a>
</td></tr>
<tr><td>
<blockquote class="subsectionBody">
<p>The release candidate typically consists of
<ul><li>assembly source and binary distributions,</li>
<li>the associated source control tag, and</li>
<li>the individual Maven module artifacts.</li>
</ul>
</p>
<p>
The source and binary distributions are manually copied by the
release manager to the Apache distribution SVN in the dev/uima spot,
to make them available for review. The Maven module artifacts
are found in the Nexus staging repository, and are available once
the release manager "closes" the repository.
</p>
<p>
After things are staged, you write a note to the dev list, asking for an approval vote.
You need to provide the url(s) of the closed staging repository in the note so the approvers
can find the code to check, the source control tag corresponding to the release, and
if needed, and the place in the distribution SVN where the source and binary
distributions being proposed are found.
The [VOTE] email should be based on similar previous votes, and
include instructions to testers on how to set up their maven settings.xml file to specify
the particular staging repository (or repositories, if more than one is being used).
For an example, see <a href="https://markmail.org/message/4ae7zb4ucmivlkaa">this dev-list post</a>.
</p>
</blockquote>
</td></tr>
</table>
<table class="subsectionTable">
<tr><td>
<a name="Releasing">
<h2>Releasing
</h2>
</a>
</td></tr>
<tr><td>
<blockquote class="subsectionBody">
<p>
After a successful release vote for the release on the dev mailing list:
<ol>
<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>Do an svn import of the new released artifacts (bin.tar/zip) to the
Apache release svn (<a href="https://dist.apache.org/repos/dist/release/uima">
https://dist.apache.org/repos/dist/release/uima</a>).
There is typically a new directory added, e.g., ruta-x.x.x or uimaj-x.x.x, etc.
</p>
<p>A suggested approach: Make a new dir in the build project, called svnUpload (or whatever),
and copy the artifacts (typically the bin/zip/tar and the source release and all the signature/checksums)
into this dir. Then do the svn command:
<pre>cd the-svnUpload-directory
svn import -m "commit msg, e.g. uimaj-2.8.0 rc5" . https://dist.apache.org/repos/dist/release/uima/xxxxxxxx-n.n.n
</pre>
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).
</p>
<!--
(which are merged with
the existing previous plugin releases already on the update site).
-->
<p>
If Eclipse plugins are being released,
the update site build will have under the target/eclipse-update-site/[subsite]
the sub-site, as checked out of the .../dist/... svn.
You can check things by doing an svn status command. "cd" to the The features
subdirectory, and do an svn add *2.5.0*,
followed by an svn commit -m "uimaj 2.5.0 release [ replace with the right message]".
Repeat for the plugins subdirectory.
Then go up to the subsite directory, and do another svn commit -m "[message]" to update
the artifacts and contents stuff.</p>
<p>
Make sure the KEYS file in release/uima is current. See
<a href="one-time-release-setup.html">one-time-release-setup</a>.
</p>
<p>Update
the download page of the UIMA website to make the new release artifacts available.
This is done indirectly, by editing both the downloads.xml page and also by
adding entries to the xdocs/stylesheets/project.xml page - follow the previous examples.</p>
</li>
<li>Things not needed to be mirrored go into our website:
in the docs/d directory.
Currently, this includes the RELEASE_NOTES (plus issuesFixed) for the release,
the new docbooks, and the Javadocs. Arrange to update these in a way that
<a href="saving-svn-resources.html">preserves SVN resources</a>.</li>
<li>Copy RELEASE_NOTES and issuesFixed
from the top level project (where
the mvn release:perform was done from) in the directory
target/checkout/ ... to the the website in docs/d/[project-version].</li>
<li>Update the downloads page of the web site</li>
<li>Update Jira version info to reflect the release status and date</li>
<li>After release appears on maven central, post an appropriate announce letter</li>
<li>Add release to next Board report</li>
<li>Celebrate!</li>
</ol>
</p>
</blockquote>
</td></tr>
</table>
<table class="subsectionTable">
<tr><td>
<a name="Announce The Release">
<h2>Announce The Release
</h2>
</a>
</td></tr>
<tr><td>
<blockquote class="subsectionBody">
<p>
To announce the published release send and email to
</p>
<ul>
<li>announce@apache.org</li>
<li>user@uima.apache.org</li>
</ul>
<p>
and describe the major changes of the release.
Announcements should be posted from the release manager's <code>apache.org</code> address,
and signed by the release manager using the same code-signing key as was used to sign the release.
For more details please refer to <a href="https://incubator.apache.org/guides/releasemanagement.html#announcements">
A Guide To Release Management During Incubation</a>.
</p>
<p>Our main uima website has a "News" section that should be updated with news of the release.
There are 2 place to update: One is the index.xml file, which has a one-line summary (at the bottom) that references
a link within the new.xml page; and a new entry in the news.xml page itself. Follow previous examples.</p>
</blockquote>
</td></tr>
</table>
</blockquote>
</p>
</td></tr>
</table>
</td>
</tr>
<!-- FOOTER -->
<tr><td colspan="2">
<hr noshade="" size="1"/>
</td></tr>
<tr><td colspan="2">
<table class="pageFooter">
<tr>
<td><a href="index.html">Home</a></td>
<td><a href="privacy-policy.html">Privacy Policy</a></td>
<td style="font-size:75%">
Copyright &#169; 2006-2013, The Apache Software Foundation.<br/>
Apache UIMA, UIMA, the Apache UIMA logo and the Apache Feather logo are trademarks of The Apache Software Foundation.<br/>
All other marks mentioned may be trademarks or registered trademarks of their respective owners.
</td>
<td><a href="mailto:dev@uima.apache.org">Contact us</a></td>
</tr>
</table>
</td></tr>
</table>
</body>
</html>