xdocs/checklist-release.xml - uima-site - Git at Google

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!--
 Licensed to the Apache Software Foundation (ASF) under one
 or more contributor license agreements.  See the NOTICE file
 distributed with this work for additional information
 regarding copyright ownership.  The ASF licenses this file
  to you under the Apache License, Version 2.0 (the
 "License"); you may not use this file except in compliance
 with the License.  You may obtain a copy of the License at

   https://www.apache.org/licenses/LICENSE-2.0

 Unless required by applicable law or agreed to in writing,
 software distributed under the License is distributed on an
 "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 KIND, either express or implied.  See the License for the
 specific language governing permissions and limitations
 under the License.
 -->
 <document>

 <properties>
 <title>Checklist: Release</title>
 <author email="dev@uima.apache.org">Apache UIMA Documentation Team</author>
 </properties>

 <body>

 <section name="Checklist: Release">

 <ol>
   <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 property in the main pom controlling the ISSUES-FIXED</li>
   <li><b>NEW ! </b>Update the parent-pom settings for API compatibility: previous version and compat.level</li>
   <li>Update the READMEs and RELEASE-NOTES.</li>
   <li>Announce on the dev list that you're doing a release so others can get any changes in, and also
       know not to be committing to trunk while you're in the middle of doing the release.</li>
   <li>Make a new build directory for this release, and source control checkout the trunk or git clone the repo and switch to the branch (if needed).
       (svn "export" instead of checkout
       fails at a later commit step by the release plugin). This is so you can
       preserve the build for later upload of selected artifacts to the distribution spot.
       <p>
       If instead you are building from an existing checkout, do a source control update to be sure the workspace is up-to-date.
       </p>
             </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>Note: this doesn't seem to work, as the purged items end up being needed by the recursive module build.
       So, instead, just go to the .m2 .../uima/ node and consider deleting that directory.</p>
     </li>
   <li>Do a full build with deploy of the (last) snapshot before release: mvn clean deploy -Papache-release</li>
   <li>If retrying a release candidate, delete the old rc-xxx in svn xxx/tags/ or the git branch for the tag.</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>
       <li>merge trunk head -> working copy (fully recursive)</li>
       <li>commit</li>
       <li>switch working copy to trunk (fully recursive)</li>
       <li>merge reintegrate branch -> trunk</li>
       <li>commit</li>
       <li>(cleanup at end- delete the old branch)</li>
     </ol>
   </li-->
   <p>More details on next steps are
     <a href="https://maven.apache.org/developers/release/apache-release.html">here</a></p>
   <ol>
     <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).
       <ol>
         <p>Release one or more artifacts into the staging repo.</p>
         <li>Scan poms to be sure there are <b>no</b> unintentional -SNAPSHOTs</li>.
         <li><code>mvn release:prepare -DdryRun</code> and diff the resulting poms
           to verify nothing unintentional is dropped or updated incorrectly</li>
           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 release:prepare [-DautoVersionSubmodules]</code>.
         Try to accept the default suggestions for names; you might change the source control tag to include a "-rc1"
         suffix indicating a release candidate number.</li>
         <li><code>mvn release:perform</code></li>
       </ol>
     </li>
     <li>Repeat above steps for all things being released in one go (not already in an aggregate).</li>
     <li>login to <a href="https://repository.apache.org">https://repository.apache.org</a>
       using your Apache LDAP credentials, find the staging artifact, and right click - "close" it
       after all things that are being included in this release are present.</li>
     <!--li>Update the trunk: for all references that should now refer to the staged release version
     </li>
     <li>build/test these</li>
     <li>commit trunk</li-->
   </ol>
   <!--li>
     Repeat above steps for all sets of dependent things where you need to update the dependencies to
     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 source control 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.
       <p>Note that the target/eclipse-update-site will have .svn files - don't delete these - they're needed when
       you decide to "publish" via comitting these to the release svn.</p></li>
   <li>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>
      And do something similar for the eclipse update sub-site.


   <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>
   </li>
   <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>For Eclipse plugins, <a href="dev-eclipse-plugin-signing.html">sign the jars</a>.</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. This is
       https://dist.apache.org/repos/dist/release/uima/uimaj-x.y.z  (replace the last with the thing being released).
       Assuming you previously promoted the release candidate to https://dist.apache.org/repos/dist/dev/uima/uimaj/xxx/yyy,
       you can use the command (modify the details, of course)
       <pre>svn copy https://dist.apache.org/repos/dist/dev/uima/uimaj/2.10.0-rc1/artifacts
         https://dist.apache.org/repos/dist/release/uima/uimaj-2.10.0 -m "release uimaj-2.10.0"
       </pre>
       <p>If adding additional new directories to the target, use the --parent parameter to tell svn to create those.</p>

             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>Eclipse update sites:
         <ul>
           <li>If you a resetting the update subsite, do these steps:
              <ol>
                <li>rename the update subsite to xxx-a.b.c-d.e.f  where a.b.c is the first version and d.e.f is the last
                  version.  You do this via svn copy command in the dist.apache.org release spot.
                  If you have a GUI tool like tortisesvn, you can use that.</li>
                <li>after the rename, wait until you see this in the archive.apache.org spot, then delete it from the
                    dist.apache.org release svn.  Although this will delete it on the apache mirror system, it will remain
                    in the archive.apache.org spot.</li>
                <li>now, checkout the dist.apache.org release subsite, and modify it by deleting items, adding items, and
                    modifying items in the working set.  Then commit these changes so the current site reflects the new
                    one.</li>
              </ol>
           </li>
           <li>Otherwise, the eclipse-update-sub-site project's output folder in the target directory should
               already be svn working copies, so you can commit these.
               <p>Commit the target/xxxx/yyyy/features, .../plugins, and the artifacts/content jars and signatures.</p>
               <p><b>DO NOT COPY the dist...dev site</b>, instead, use the build's update site with the signed jars, and just "commit" it.
                </p>
               If using Windows and have tortise svn installed, cd to the target/eclipse-update-site/uimaj (or wherever your update site
               was built) and right click and say commit (and click the "all" selection to upload the new files).
           </li>
         </ul>
       </li>

       <li>Check the www.apache.org/dist/uima site using
           <a target="_blank" rel="noopener" href=" https://checker.apache.org/projs/uima.html"> https://checker.apache.org/projs/uima.html</a></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
       website under the uima.apache.org/d/ (non-SVN source) directory.  Update the index.html
       as needed for the version.
   </li>
   <!--li>Copy released artifacts to targets: bin, src, p.a.o/www/www.apache.org/dist/uima,
       new features / plugins from Eclipse update site target/eclipse-update-site to .../dist/uima/eclipse-update-site
       (add to what's already there).</li-->
   <!-- li>Copy released artifacts to targets: bin, src, p.a.o/www/www.apache.org/dist/uima. <u>TEMPORARY:</u>
       Copy the updated composite repository from eclipse-packagings/eclipse-update-site to .../dist/uima/eclipse-update-site.</li-->
   <li>Copy RELEASE_NOTES and issuesFixed, and maybe api-change-report
       from the .../target/checkout where
       the mvn release:perform was done from to the UIMA web site in doc/d/[project-version].</li>
   <li>If using links to api change report, insert needed folders and copy api change report.  For example,
       for uimaj: insert uimaj-core folder into .../d/uimaj-x.y.z and copy in the api change report from uimaj-core.</li>
   <li>update the current-release folder, if in use.  Do this by doing an svn copy from uima-website/docs/d/xxx-y.y.y to
   .../docs/d/xxx-current.  It's convenient to use tortise-svn: navigate to the docs/d, select uimaxxx-y.y.y folder, and then
   right-click and pick copy to ...  and specify docs/d/uimzxxx-current folder.</li>
   <li>Update the downloads page of the web site, and the xdocs/stylesheets/project.xml for the new release.</li>
   <li>Update Jira version info to reflect the release status and date</li>
   <li>Log into <a target="_blank" rel="noopener" href="https://reporter.apache.org/addrelease.html?uima">
   https://reporter.apache.org/addrelease.html?uima</a> and add release data (e.g. uimaj-2.10.0 2017-04-04).</li>
   <li>Fixup the tag.
     <ul><li>SVN: Fix the SVN tag for the release candidate if needed, removing any -rcXX, to indicate the release.</li>
         <li>GIT: make a new tag for the release with the name rel/...tag-name.
           <ul><li><code>git tag -m "proj-name-1.2.3 rcXXX released" rel/proj-name-x.y.z proj-name-x.y.z^{}</code>
          The strange notation ^{} peels the annotated tag and returns a ref to the actual commit.</li>
          <li><code>git push origin rel/proj-name-x.y.z</code> This updates the remote repo with the new tag.</li>
          <li><p>Merge the release branch (if one was made) into the main branch.  You can use the github.com site
          to do this: make a pull request targeting the master, from the release branch, and after checks pass,
          accept the pull.   Alternatively, you can pull from the release branch into the master
          in a local checkout, and push the result.</p>
          <p>If no release branch was made, then the maven release prepare/perform will have already updated
          the master to the next snapshot level.</p></li>
          </ul>
         </li>
     </ul>
   </li>
   <li>After release appears on maven central, post an appropriate announce letter</li>
   <li>Add a news item for the release</li>
   <li>Tweet about the release</li>
   <li>Add release to next Board report</li>
   <li>Celebrate :-)</li>
 </ol>
 </section>

 </body>
 </document>
	<?xml version="1.0" encoding="ISO-8859-1"?>
	<!--
	Licensed to the Apache Software Foundation (ASF) under one
	or more contributor license agreements. See the NOTICE file
	distributed with this work for additional information
	regarding copyright ownership. The ASF licenses this file
	to you under the Apache License, Version 2.0 (the
	"License"); you may not use this file except in compliance
	with the License. You may obtain a copy of the License at

	https://www.apache.org/licenses/LICENSE-2.0

	Unless required by applicable law or agreed to in writing,
	software distributed under the License is distributed on an
	"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
	KIND, either express or implied. See the License for the
	specific language governing permissions and limitations
	under the License.
	-->
	<document>

	<properties>
	<title>Checklist: Release</title>
	<author email="dev@uima.apache.org">Apache UIMA Documentation Team</author>
	</properties>

	<body>

	<section name="Checklist: Release">

	<ol>
	<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 property in the main pom controlling the ISSUES-FIXED</li>
	<li><b>NEW ! </b>Update the parent-pom settings for API compatibility: previous version and compat.level</li>
	<li>Update the READMEs and RELEASE-NOTES.</li>
	<li>Announce on the dev list that you're doing a release so others can get any changes in, and also
	know not to be committing to trunk while you're in the middle of doing the release.</li>
	<li>Make a new build directory for this release, and source control checkout the trunk or git clone the repo and switch to the branch (if needed).
	(svn "export" instead of checkout
	fails at a later commit step by the release plugin). This is so you can
	preserve the build for later upload of selected artifacts to the distribution spot.
	<p>
	If instead you are building from an existing checkout, do a source control update to be sure the workspace is up-to-date.
	</p>
	</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>Note: this doesn't seem to work, as the purged items end up being needed by the recursive module build.
	So, instead, just go to the .m2 .../uima/ node and consider deleting that directory.</p>
	</li>
	<li>Do a full build with deploy of the (last) snapshot before release: mvn clean deploy -Papache-release</li>
	<li>If retrying a release candidate, delete the old rc-xxx in svn xxx/tags/ or the git branch for the tag.</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>
	<li>merge trunk head -> working copy (fully recursive)</li>
	<li>commit</li>
	<li>switch working copy to trunk (fully recursive)</li>
	<li>merge reintegrate branch -> trunk</li>
	<li>commit</li>
	<li>(cleanup at end- delete the old branch)</li>
	</ol>
	</li-->
	<p>More details on next steps are
	<a href="https://maven.apache.org/developers/release/apache-release.html">here</a></p>
	<ol>
	<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).
	<ol>
	<p>Release one or more artifacts into the staging repo.</p>
	<li>Scan poms to be sure there are <b>no</b> unintentional -SNAPSHOTs</li>.
	<li><code>mvn release:prepare -DdryRun</code> and diff the resulting poms
	to verify nothing unintentional is dropped or updated incorrectly</li>
	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 release:prepare [-DautoVersionSubmodules]</code>.
	Try to accept the default suggestions for names; you might change the source control tag to include a "-rc1"
	suffix indicating a release candidate number.</li>
	<li><code>mvn release:perform</code></li>
	</ol>
	</li>
	<li>Repeat above steps for all things being released in one go (not already in an aggregate).</li>
	<li>login to <a href="https://repository.apache.org">https://repository.apache.org</a>
	using your Apache LDAP credentials, find the staging artifact, and right click - "close" it
	after all things that are being included in this release are present.</li>
	<!--li>Update the trunk: for all references that should now refer to the staged release version
	</li>
	<li>build/test these</li>
	<li>commit trunk</li-->
	</ol>
	<!--li>
	Repeat above steps for all sets of dependent things where you need to update the dependencies to
	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 source control 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.
	<p>Note that the target/eclipse-update-site will have .svn files - don't delete these - they're needed when
	you decide to "publish" via comitting these to the release svn.</p></li>
	<li>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>
	And do something similar for the eclipse update sub-site.


	<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>
	</li>
	<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>For Eclipse plugins, <a href="dev-eclipse-plugin-signing.html">sign the jars</a>.</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. This is
	https://dist.apache.org/repos/dist/release/uima/uimaj-x.y.z (replace the last with the thing being released).
	Assuming you previously promoted the release candidate to https://dist.apache.org/repos/dist/dev/uima/uimaj/xxx/yyy,
	you can use the command (modify the details, of course)
	<pre>svn copy https://dist.apache.org/repos/dist/dev/uima/uimaj/2.10.0-rc1/artifacts
	https://dist.apache.org/repos/dist/release/uima/uimaj-2.10.0 -m "release uimaj-2.10.0"
	</pre>
	<p>If adding additional new directories to the target, use the --parent parameter to tell svn to create those.</p>

	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>Eclipse update sites:
	<ul>
	<li>If you a resetting the update subsite, do these steps:
	<ol>
	<li>rename the update subsite to xxx-a.b.c-d.e.f where a.b.c is the first version and d.e.f is the last
	version. You do this via svn copy command in the dist.apache.org release spot.
	If you have a GUI tool like tortisesvn, you can use that.</li>
	<li>after the rename, wait until you see this in the archive.apache.org spot, then delete it from the
	dist.apache.org release svn. Although this will delete it on the apache mirror system, it will remain
	in the archive.apache.org spot.</li>
	<li>now, checkout the dist.apache.org release subsite, and modify it by deleting items, adding items, and
	modifying items in the working set. Then commit these changes so the current site reflects the new
	one.</li>
	</ol>
	</li>
	<li>Otherwise, the eclipse-update-sub-site project's output folder in the target directory should
	already be svn working copies, so you can commit these.
	<p>Commit the target/xxxx/yyyy/features, .../plugins, and the artifacts/content jars and signatures.</p>
	<p><b>DO NOT COPY the dist...dev site</b>, instead, use the build's update site with the signed jars, and just "commit" it.
	</p>
	If using Windows and have tortise svn installed, cd to the target/eclipse-update-site/uimaj (or wherever your update site
	was built) and right click and say commit (and click the "all" selection to upload the new files).
	</li>
	</ul>
	</li>

	<li>Check the www.apache.org/dist/uima site using
	<a target="_blank" rel="noopener" href=" https://checker.apache.org/projs/uima.html"> https://checker.apache.org/projs/uima.html</a></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
	website under the uima.apache.org/d/ (non-SVN source) directory. Update the index.html
	as needed for the version.
	</li>
	<!--li>Copy released artifacts to targets: bin, src, p.a.o/www/www.apache.org/dist/uima,
	new features / plugins from Eclipse update site target/eclipse-update-site to .../dist/uima/eclipse-update-site
	(add to what's already there).</li-->
	<!-- li>Copy released artifacts to targets: bin, src, p.a.o/www/www.apache.org/dist/uima. <u>TEMPORARY:</u>
	Copy the updated composite repository from eclipse-packagings/eclipse-update-site to .../dist/uima/eclipse-update-site.</li-->
	<li>Copy RELEASE_NOTES and issuesFixed, and maybe api-change-report
	from the .../target/checkout where
	the mvn release:perform was done from to the UIMA web site in doc/d/[project-version].</li>
	<li>If using links to api change report, insert needed folders and copy api change report. For example,
	for uimaj: insert uimaj-core folder into .../d/uimaj-x.y.z and copy in the api change report from uimaj-core.</li>
	<li>update the current-release folder, if in use. Do this by doing an svn copy from uima-website/docs/d/xxx-y.y.y to
	.../docs/d/xxx-current. It's convenient to use tortise-svn: navigate to the docs/d, select uimaxxx-y.y.y folder, and then
	right-click and pick copy to ... and specify docs/d/uimzxxx-current folder.</li>
	<li>Update the downloads page of the web site, and the xdocs/stylesheets/project.xml for the new release.</li>
	<li>Update Jira version info to reflect the release status and date</li>
	<li>Log into <a target="_blank" rel="noopener" href="https://reporter.apache.org/addrelease.html?uima">
	https://reporter.apache.org/addrelease.html?uima</a> and add release data (e.g. uimaj-2.10.0 2017-04-04).</li>
	<li>Fixup the tag.
	<ul><li>SVN: Fix the SVN tag for the release candidate if needed, removing any -rcXX, to indicate the release.</li>
	<li>GIT: make a new tag for the release with the name rel/...tag-name.
	<ul><li><code>git tag -m "proj-name-1.2.3 rcXXX released" rel/proj-name-x.y.z proj-name-x.y.z^{}</code>
	The strange notation ^{} peels the annotated tag and returns a ref to the actual commit.</li>
	<li><code>git push origin rel/proj-name-x.y.z</code> This updates the remote repo with the new tag.</li>
	<li><p>Merge the release branch (if one was made) into the main branch. You can use the github.com site
	to do this: make a pull request targeting the master, from the release branch, and after checks pass,
	accept the pull. Alternatively, you can pull from the release branch into the master
	in a local checkout, and push the result.</p>
	<p>If no release branch was made, then the maven release prepare/perform will have already updated
	the master to the next snapshot level.</p></li>
	</ul>
	</li>
	</ul>
	</li>
	<li>After release appears on maven central, post an appropriate announce letter</li>
	<li>Add a news item for the release</li>
	<li>Tweet about the release</li>
	<li>Add release to next Board report</li>
	<li>Celebrate :-)</li>
	</ol>
	</section>

	</body>
	</document>