| <!--- |
| 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 |
| |
| http://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. |
| --> |
| |
| <html> |
| <head> |
| <meta charset="utf-8"> |
| <title>Apache Yetus</title> |
| <meta name="viewport" content="width=device-width, initial-scale=1.0"> |
| <meta name="description" content=""> |
| <meta name="author" content=""> |
| |
| <link href="../../assets/css/bootstrap.css" rel="stylesheet"> |
| <link href="../../assets/css/bootstrap-theme.css" rel="stylesheet"> |
| <link href="../../assets/css/font-awesome.css" rel="stylesheet"> |
| |
| <!-- JS --> |
| <script type="text/javascript" src="../../assets/js/jquery-2.1.4.min.js"></script> |
| <script type="text/javascript" src="../../assets/js/bootstrap.js"></script> |
| </head> |
| <body> |
| |
| <div class="navbar navbar-inverse navbar-static-top" role="navigation"> |
| <div class="container"> |
| <div class="navbar-header"> |
| <button type="button" class="navbar-toggle" data-toggle="collapse" data-target=".navbar-collapse"> |
| <span class="sr-only">Toggle navigation</span> |
| <span class="icon-bar"></span> |
| <span class="icon-bar"></span> |
| <span class="icon-bar"></span> |
| </button> |
| <a class="img-responsive pull-left" href="/"> |
| <img style="max-height: 40px; margin-top: 5px; margin-bottom: 5px;" src="../../assets/img/yetus_logo.png" alt="Apache Yetus logo" /> |
| </a> |
| </div> |
| <div class="navbar-collapse collapse"> |
| <ul class="nav navbar-nav"> |
| <li><a href="/downloads/">Downloads</a> |
| <li class="dropdown"> |
| <a class="dropdown-toggle" data-toggle="dropdown" href="#">Documentation <span class="caret"></span></a> |
| <ul class="dropdown-menu" role="menu"> |
| <li><a href="/documentation/0.13.0/">Docs for v0.13.0</a></li> |
| <li><a href="/documentation/0.14.1/">Docs for v0.14.1</a></li> |
| <li><a href="/documentation/0.15.0/">Docs for v0.15.0</a></li> |
| <li><a href="/documentation/in-progress/">In Progress Docs for Contributors</a> |
| </li> |
| <li><a href="/documentation/history/">History of the Project</a> |
| </li> |
| </ul> |
| </li> |
| <li class="dropdown"> |
| <a class="dropdown-toggle" data-toggle="dropdown" href="#">Get Involved <span class="caret"></span></a> |
| <ul class="dropdown-menu" role="menu" aria-labelledby="drop1"> |
| <li role="presentation"><a role="menuitem" tabindex="-1" href="/mailinglists"><i class="fa fa-commenting"></i> Mailing Lists</a> |
| </li> |
| <li role="presentation"><a role="menuitem" tabindex="-1" href="https://issues.apache.org/jira/browse/YETUS"><i class="fa fa-bug"></i> JIRA (Bugs)</a> |
| </li> |
| <li role="presentation"><a role="menuitem" tabindex="-1" href="https://gitbox.apache.org/repos/asf/yetus.git"><i class="fa fa-code"></i> Source (Apache)</a> |
| </li> |
| <li role="presentation"><a role="menuitem" tabindex="-1" href="https://github.com/apache/yetus"><i class="fa fa-github-alt"></i> Source (GitHub)</a> |
| </li> |
| <li role="presentation"><a role="menuitem" tabindex="-1" href="/contribute/"><i class="fa fa-code-fork"></i> Contributing</a> |
| </li> |
| <li role="presentation"><a role="menuitem" tabindex="-1" href="https://twitter.com/ApacheYetus"><i class="fa fa-twitter"></i> @ApacheYetus</a> |
| </li> |
| </ul> |
| </li> |
| <li> |
| <li class="dropdown"> |
| <a class="dropdown-toggle" data-toggle="dropdown" href="#">Apache Software Foundation <b class="caret"></b></a> |
| <ul class="dropdown-menu" role="menu"> |
| <li><a href="https://www.apache.org">Apache Homepage</a> |
| </li> |
| <li><a href="https://www.apache.org/licenses/">Apache License</a> |
| </li> |
| <li><a href="https://www.apache.org/foundation/sponsorship.html">Sponsorship</a> |
| </li> |
| <li><a href="https://www.apache.org/foundation/thanks.html">Thanks</a> |
| </li> |
| <li><a href="https://www.apache.org/security/">Security</a> |
| </li> |
| </ul> |
| </li> |
| </li> |
| </ul> |
| </div> |
| <!--/.nav-collapse --> |
| </div> |
| </div> |
| |
| <div class="container"> |
| <!-- |
| 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 |
| |
| http://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. |
| --> |
| <!-- markdownlint-disable no-bare-urls --> |
| |
| <h1 id="managing-a-release">Managing a Release</h1> |
| |
| <!-- MarkdownTOC levels="1,2" autolink="true" bullets="-,+,*" --> |
| |
| <ul> |
| <li><a href="#dependencies">Dependencies</a></li> |
| <li><a href="#setup">Setup</a></li> |
| <li><a href="#verify-changelog-and-release-notes">Verify Changelog and Release Notes</a></li> |
| <li><a href="#release-candidates">Release Candidate(s)</a></li> |
| <li><a href="#verification">Verification</a></li> |
| <li><a href="#cleanup">Cleanup</a></li> |
| </ul> |
| |
| <!-- /MarkdownTOC --> |
| |
| <p>The Apache Yetus community encourages all committers to help on driving releases. To that end, this section seeks to outline the tools and process you'll use when managing a release. Note that these are our community norms; they do not supersede foundation policy should the two disagree.</p> |
| |
| <h2 id="dependencies">Dependencies</h2> |
| |
| <p>First, let's review what you'll need to complete all steps of the process.</p> |
| |
| <h3 id="committer-access">Committer Access</h3> |
| |
| <p>While the Yetus project aims to get new contributors involved in as much of the project as possible, ASF policy requires that all <a href="https://www.apache.org/foundation/glossary.html#ReleaseManager">Release Managers be committers on the project</a>. As a practical matter, <a href="https://www.apache.org/dev/release.html#stage">release candidates are staged in a project-specific svn repository that only project committers have write access to</a>.</p> |
| |
| <h3 id="hardware-you-own-and-physically-control">Hardware You Own and Physically Control</h3> |
| |
| <p>ASF release policy requires that release manager verification and signing of artifacts take place on hardware you have as much control over as possible. This is because your private signing keys will be involved and those <em>should</em> only be accessible on such hardware, to minimize the exposure to third parties. For more details, <a href="https://www.apache.org/dev/release.html#owned-controlled-hardware">see the ASF release policy's relevant text</a>.</p> |
| |
| <h3 id="cryptographic-signing-tools-and-keys">Cryptographic Signing Tools and Keys</h3> |
| |
| <p>Everything distributed by an ASF project must be signed before distribution (ref ASF release policy <a href="https://www.apache.org/dev/release.html#what-must-every-release-contain">on releases</a> and <a href="https://www.apache.org/dev/release.html#distribute-other-artifacts">supplemental artifacts</a>). The short version of the rationale is that downstream users should be able to verify that the artifacts they make use of were ones blessed by the project PMC. For a longer explanation, <a href="https://www.apache.org/dev/release-signing.html#motivation">see the ASF release signing document's motivation section</a>.</p> |
| |
| <p>In practice, the requirement for artifact signing is handled via OpenPGP signatures. For all practical purposes, this means you'll need to use Gnu Privacy Guard (aka GnuPG or GPG). It also means you'll need to have a public/private key pair you control that is published in your name. Thankfully, the ASF provides an excellent overview to using GPG in <a href="https://www.apache.org/dev/openpgp.html">the ASF OpenPGP guide</a>. In particular, if you don't already have a published key be sure to follow the instructions in the section <a href="https://www.apache.org/dev/openpgp.html#generate-key">How To Generate A Strong Key</a>.</p> |
| |
| <h3 id="version-control-system-tools">Version Control System Tools</h3> |
| |
| <p>In addition to the git tools you normally use to interact with the Yetus project, managing a release also requires a properly configured Apache Subversion installation. This additional tool is because both the staging area for release candidates and the final distribution mechanism for PMC approved releases rely on Subversion.</p> |
| |
| <p>The Subversion project provides a nice set of pointers to installing on various OSes, in most cases via package managers, on their page <a href="https://subversion.apache.org/packages.html">Apache Subversion Binary Packages</a>. Alternatively, you could start with a source release and manually build the necessary tools by starting at <a href="https://subversion.apache.org/download.cgi">Apache Subversion - Download Source Code</a>.</p> |
| |
| <h3 id="project-specific-build-tools">Project Specific Build Tools</h3> |
| |
| <p>To create our convenience binary artifact and the Apache Maven plug-ins, you'll need to build both our project docs and all of the individual components.<br /> |
| All of the tools will be in the Docker container that is launched by using the <code>./start-build-dev.sh</code> script. Note that you will need to have a properly<br /> |
| configured GnuPG and Maven settings.xml setup.</p> |
| |
| <h2 id="setup">Setup</h2> |
| |
| <p>When you first start managing a given release, you'll have to take care of the following tasks. Except for creating the release staging branch, these can be done in any order.</p> |
| |
| <h3 id="verify-the-year">Verify the Year</h3> |
| |
| <p>Before attempting to do a release, verify that the documentation, website, etc, has the current year in the copyright notices. Given that fixing that requires a patch, this should be done in advance of other release work!</p> |
| |
| <h3 id="ensure-your-public-key-is-in-keys">Ensure Your Public Key is in KEYS</h3> |
| |
| <p>Like many ASF projects, we provide a single file that downstream folks can use to verify our release artifacts. It's located in the project's distribution area <a href="https://downloads.apache.org/yetus">https://downloads.apache.org/yetus</a>. You can read about this file in the <a href="https://www.apache.org/dev/release-signing">ASF guide to release signing</a> section. If your public key is not already included in <a href="https://downloads.apache.org/yetus/KEYS">the KEYS file</a>, you will need to add it. You can either follow the instructions in the previously mentioned guide or those at the top of the actual KEYS file. In any case, you will need to use Subversion to update the KEYS file in the project's distribution area. Note that this area is writable only by the project PMC. If you are not yet on the PMC, your last step should be providing a patch rather than committing.</p> |
| |
| <p>Example commands:</p> |
| |
| <div class="highlight"><pre class="highlight shell"><code><span class="nv">$ </span>svn co https://dist.apache.org/repos/dist/release/yetus yetus-dist-release |
| <span class="nv">$ </span><span class="nb">cd </span>yetus-dist-release |
| <span class="nv">$ </span><span class="o">(</span>gpg <span class="nt">--list-sigs</span> <your key name> <span class="o">&&</span> gpg <span class="nt">--armor</span> <span class="nt">--export</span> <your key name><span class="o">)</span> <span class="o">>></span> KEYS |
| <span class="nv">$ </span>svn diff |
| <span class="nv">$ </span>svn commit <span class="nt">-m</span> <span class="s2">"Added myself to KEYS."</span> |
| </code></pre></div> |
| <h3 id="work-in-jira">Work in JIRA</h3> |
| |
| <p>Like the rest of our project activity, we'll use an issue in JIRA to track managing the release. You should create this issue and assign it to yourself. As you make your way through the process of creating and running votes on release candidates, this issue will give you a centralized place to collect pointers to your work.</p> |
| |
| <ol> |
| <li>Browse to the ASF JIRA instance's "create issue" page: <a href="https://issues.apache.org/jira/secure/CreateIssue!default.jspa">https://issues.apache.org/jira/secure/CreateIssue!default.jspa</a></li> |
| <li>Select "Yetus" for the Project and "Task" for the issue type. Click "Next".</li> |
| <li>On the next screen, use a subject line like "Release VERSION", with an appropriate version number. Fill in the following fields and click "Create". |
| <ul> |
| <li>The component should be "website and documentation"</li> |
| <li>Affects Version and Fix Version should both be the version you are releasing</li> |
| <li>Assignee should be you</li> |
| <li>Add a description similar to "Generate release candidates as needed to create a VERSION release." with an appropriate version number.</li> |
| </ul> |
| </li> |
| <li>Next, create a shortened link to the JIRA version's release notes. This link should use the ASF link shortener, <a href="https://s.apache.org/">https://s.apache.org/</a>. To find the appropriate release notes page: |
| <ul> |
| <li>Browse to the Yetus JIRA versions page: <a href="https://issues.apache.org/jira/browse/YETUS/?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel">https://issues.apache.org/jira/browse/YETUS/?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel</a></li> |
| <li>Click on the Name of the release you are managing</li> |
| <li>Click on the "Release Notes" button. If it isn't shown, click on the "Summary" button in the left menu</li> |
| <li>Copy this URL</li> |
| </ul> |
| </li> |
| <li>Browse to the ASF URL shortener: <a href="https://s.apache.org/">https://s.apache.org/</a></li> |
| <li>Paste the URL into the "URI" field</li> |
| <li>Set the optional key field to 'yetus-_version_-jira'<br /> |
| For example, on the 0.7.0 release, you would use <code>https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318920&version=12334330</code> for the URI field and 'yetus-0.7.0-jira' for the key.</li> |
| <li>Finally, you should create a JIRA version that matches the release <em>following</em> the one you are managing. This action is so that folks can continue to work on things that won't make it into the in-progress release while we evaluate candidates. |
| <ol> |
| <li>Browse to the ASF JIRA project management page for versions: <a href="https://issues.apache.org/jira/plugins/servlet/project-config/YETUS/versions">https://issues.apache.org/jira/plugins/servlet/project-config/YETUS/versions</a></li> |
| <li>Fill in a version one minor version up from the release you're managing. E.g., when managing the 0.7.0 release, fill in 0.8.0.</li> |
| <li>Set a start date of today.</li> |
| <li>Click "Add"</li> |
| </ol> |
| </li> |
| </ol> |
| |
| <h3 id="work-in-git">Work in Git</h3> |
| |
| <p>Once you have an issue to track things, git branches will be needed in order to make the necessary<br /> |
| PRs. A script is provided to make this easier:</p> |
| |
| <ul> |
| <li> |
| <p>Major Release:</p> |
| |
| <div class="highlight"><pre class="highlight shell"><code><span class="nv">$ </span>release/initial-patches.sh <span class="nt">--jira</span><span class="o">=</span><release JIRA> <span class="nt">--version</span><span class="o">=</span><X.0.0> |
| </code></pre></div> </li> |
| <li> |
| <p>Minor release:</p> |
| |
| <div class="highlight"><pre class="highlight shell"><code><span class="nv">$ </span>release/initial-patches.sh <span class="nt">--jira</span><span class="o">=</span><release JIRA> |
| </code></pre></div> </li> |
| <li> |
| <p>Micro release:</p> |
| |
| <div class="highlight"><pre class="highlight shell"><code><span class="nv">$ </span>release/initial-patches.sh <span class="nt">--jira</span><span class="o">=</span><release JIRA> <span class="nt">--startingbranch</span><span class="o">=</span>rel/<previous micro version> |
| </code></pre></div> </li> |
| </ul> |
| |
| <p>These commands will create one or two branches:</p> |
| |
| <ul> |
| <li><em>JIRA</em>-release with updated poms that match the release you are working on</li> |
| <li><em>JIRA</em>-main with updated poms that match the next SNAPSHOT release</li> |
| </ul> |
| |
| <p>Verify the automated commits to these branches are correct and create the necessary PRs.<br /> |
| Once Apache Yetus checks finish, merge in the <em>JIRA-release</em> and send a message<br /> |
| to dev@yetus.apache.org that main is now frozen for release. The <em>JIRA-main</em> branch<br /> |
| will get merged in after release.</p> |
| |
| <h2 id="verify-changelog-and-release-notes">Verify Changelog and Release Notes</h2> |
| |
| <p>Before starting work on the release candidate, it is generally a good idea to look over<br /> |
| the changelog and release notes. These files are part of our distribution and if they<br /> |
| are incorrect, will require a new RC. Therefore, before cutting a new release, make sure<br /> |
| they do not have errors or missing information. The easiest way to do this check is to<br /> |
| run through the <a href="../website">website</a> directions to update the live website. After doing<br /> |
| that work, they should be listed <a href="/downloads/releasenotes/">here</a> as the top entry.</p> |
| |
| <h2 id="release-candidates">Release Candidate(s)</h2> |
| |
| <p>Depending on how candidate evaluation goes, you may end up performing these steps multiple times. Before you start, you'll need to decide when you want each candidate's vote thread to end. ASF policy requires a minimum voting period of 72 hours (ref <a href="https://www.apache.org/foundation/voting.html">ASF Voting Policy</a>), so you should ensure enough padding to complete the candidate generation process in time. Ideally, you would plan to post the vote thread on a Friday morning (US time) with a closing date on Monday morning (US time).</p> |
| |
| <ol> |
| <li>Update JIRA version release date. Browse to the JIRA project version management page <a href="https://issues.apache.org/jira/plugins/servlet/project-config/YETUS/versions">https://issues.apache.org/jira/plugins/servlet/project-config/YETUS/versions</a>, mark the version as 'Release', and set the release date. Our generated release notes will use this date. Note that this will close the version and no one will be able to assign new JIRA issues to it. However it is required for the <code>build-and-sign</code> step below.</li> |
| <li>Update your <code>${HOME}/.m2/settings.xml</code> file to include the Maven snapshot information as indicated on <a href="https://www.apache.org/dev/publishing-maven-artifacts.html">https://www.apache.org/dev/publishing-maven-artifacts.html</a></li> |
| <li> |
| <p>Build release artifacts. Run the following from the <em>release staging branch</em> (<code>JIRA-release</code>) created by the <code>release/initial-patches.sh</code> script and run these commands:</p> |
| |
| <div class="highlight"><pre class="highlight shell"><code><span class="nv">$ </span>git checkout YETUS-XXX-release |
| <span class="nv">$ </span>./start-build-env.sh |
| <span class="o">(</span>container build and eventually a shell <span class="k">in </span>your <span class="nb">source </span>repo<span class="o">)</span> |
| <span class="nv">$ </span>release/build-and-sign.sh <span class="nt">--asfrelease</span> |
| <span class="nv">$ </span><span class="nb">ls</span> <span class="nt">-lah</span> yetus-dist/target/artifacts/<span class="k">*</span> |
| </code></pre></div> </li> |
| <li>Before exiting the container, peruse the <code>/tmp/build-log</code> directory to see if any relevant errors occurred.</li> |
| <li>Exit the container.</li> |
| <li> |
| <p>Check out the staging area for release candidates and make a directory for this candidate, somewhere outside of your working directory. Copy the artifacts from the previous step into place. For example, when working on RC1 for the 0.7.0 release</p> |
| |
| <div class="highlight"><pre class="highlight shell"><code><span class="nv">$ </span>svn co https://dist.apache.org/repos/dist/dev/yetus/ yetus-dist-dev |
| <span class="nv">$ </span><span class="nb">cd </span>yetus-dist-dev |
| <span class="nv">$ </span><span class="nb">mkdir </span>0.7.0-RC1 |
| <span class="nv">$ </span><span class="nb">cd </span>0.7.0-RC1 |
| <span class="nv">$ </span><span class="nb">cp </span>path/to/yetus/yetus-dist/target/artifacts/<span class="k">*</span> <span class="nb">.</span> |
| </code></pre></div> </li> |
| <li> |
| <p>Push the release candidate to staging distribution. This will make the artifacts visible for the vote.</p> |
| |
| <div class="highlight"><pre class="highlight shell"><code><span class="nv">$ </span><span class="nb">cd</span> .. |
| <span class="nv">$ </span>svn add 0.7.0-RC1 |
| <span class="nv">$ </span>svn commit <span class="nt">-m</span> <span class="s2">"stage Apache Yetus 0.7.0-RC1"</span> |
| Afterward, the artifacts should be visible via the web under the same URL used when checking out. In the <span class="k">case</span> of 0.7.0-RC1: <https://dist.apache.org/repos/dist/dev/yetus/0.7.0-RC1/> |
| </code></pre></div> </li> |
| <li>Examine staged maven build. Go to the <a href="https://repository.apache.org/">ASF repository</a> and log in with your asf LDAP credentials. Look for the staging repository with a name that includes "yetus". Clicking on it will give you a link to an "Open" repository. You can examine the structure in the Nexus API while you're logged in. If it looks essentially correct, "Close" the repository. Refreshing and clicking on the repository will give you a link in the Summary tab that other folks can use to interact with the repository.</li> |
| <li>Create a short link that should point to some online timezone conversion utility that will point to when the vote will end. ASF votes often use timeanddate.com's Event Time Announcer: <a href="https://www.timeanddate.com/worldclock/fixedform.html">https://www.timeanddate.com/worldclock/fixedform.html</a>.</li> |
| <li> |
| <p>Call a vote on the release candidate. At this point, you have everything you need to call a vote. Your vote thread must contain "[VOTE]" in the subject line, a link to the candidate staging area you created, a source repository commit hash, and voting rules. It should also contain hashes for the artifacts. Here is an example draft for 0.7.0-RC1, update it as appropriate for your release:</p> |
| |
| <div class="highlight"><pre class="highlight plaintext"><code> Subject: [VOTE] Apache Yetus 0.7.0-RC1 |
| |
| Artifacts are available: |
| |
| https://dist.apache.org/repos/dist/dev/yetus/0.7.0-RC1/ |
| |
| As of this vote the relevant sha512 hashes are: |
| SHA512 (CHANGELOG.md) = 6dbb09360b3116d12aed275d223f43b50a95e80aab1981d5bb61886ceb4b3b57475c976e9465f3fb28daaf62b8cae113b8ee87eae35a212c861fbc434632073b |
| SHA512 (RELEASENOTES.md) = 72a12eb96f32d35a7660967caf2ce5261bd7829ddc56962c97c7b1e71cebfa026c055258a9db1b475581ca0a3ae13d9f9651724573cacaaad9972a89ff809875 |
| SHA512 (yetus-0.7.0-bin.tar.gz) = 28f8c94fb2e22a70674be6070f63badf98e1b022ee25c171fff9629d82ca899fc7eb509ffee2a5c50f2bec10cbb20632fb9fddcab5ebcf5c2511a3ae7edbc56b |
| SHA512 (yetus-0.7.0-src.tar.gz) = 316cf36c97b301233a9b163c8b8d7ec47bdd3d042b1821820b8ac917e5668e610ec8c35fd438e45a64e05215b183ce1ad7321065883fb84ccac8b4744a7fb73e |
| |
| Source repository commit: 1e8f4588906a51317207092bd97b35687f2e3fa3 |
| Maven staging repository: https://repository.apache.org/content/repositories/orgapacheyetus-1011 |
| |
| Our KEYS file is at: https://downloads.apache.org/yetus/KEYS |
| All artifacts are signed with my key (DEADBEEF) |
| |
| JIRA version: https://s.apache.org/yetus-0.7.0-jira |
| |
| Please take a few minutes to verify the release[1] and vote on releasing it: |
| |
| [ ] +1 Release this package as Apache Yetus 0.7.0 |
| [ ] +0 no opinion |
| [ ] -1 Do not release this package because... |
| |
| The vote will be subject to Majority Approval[2] and will close at 8:00 PM |
| UTC on Monday, Xxx XXth, 2018[3]. |
| |
| [1]: https://www.apache.org/info/verification.html |
| [2]: https://www.apache.org/foundation/glossary.html#MajorityApproval |
| [3]: to find this in your local timezone see: |
| https://s.apache.org/yetus-0.7.0-rc1-close |
| </code></pre></div> </li> |
| <li>Close the vote after the deadline. Once the deadline in the vote thread passes, tally the vote and post a suitable response that changes the subject line to start with "[RESULT]". If the vote failed, ensure there are issues in JIRA for any problems brought up. When they are closed, repeat the steps for creating a release candidate. If the vote passed, proceed to the <a href="#cleanup">Cleanup section</a></li> |
| </ol> |
| |
| <h2 id="verification">Verification</h2> |
| |
| <p>You are free to make whatever checks of our release candidate artifacts suit your use, but before voting, there are certain checks you must perform according to ASF policy. This section will walk you through the required checks and give some guidelines on additional checks you may find useful. Besides the fact that downloading the release artifacts must happen first, generally, you can perform these in any order that suits you.</p> |
| |
| <h3 id="download-release-artifacts">Download release artifacts</h3> |
| |
| <p>You will need to download the release candidate files, include the artifacts and accompanying signatures and checksum files. The directory containing them should be in the [VOTE] thread. You can use wget or a similar tool to recursively grab all the files rather than download them one at a time. If you are not familiar with wget, it will create a nested set of directories based on the structure of the hosting site for release candidates.</p> |
| |
| <p>For example, if we use the URL from our exemplar VOTE email, the process would look like this:</p> |
| |
| <div class="highlight"><pre class="highlight shell"><code><span class="nv">$ </span>wget <span class="nt">--recursive</span> <span class="nt">--no-parent</span> <span class="nt">--quiet</span> <span class="s1">'https://dist.apache.org/repos/dist/dev/yetus/0.7.0-RC1/'</span> |
| <span class="nv">$ </span>find dist.apache.org/ <span class="nt">-type</span> f |
| |
| dist.apache.org//repos/dist/dev/yetus/0.7.0-RC1/CHANGELOG.md |
| dist.apache.org//repos/dist/dev/yetus/0.7.0-RC1/CHANGELOG.md.asc |
| dist.apache.org//repos/dist/dev/yetus/0.7.0-RC1/CHANGELOG.md.sha512 |
| dist.apache.org//repos/dist/dev/yetus/0.7.0-RC1/CHANGELOG.md.mds |
| dist.apache.org//repos/dist/dev/yetus/0.7.0-RC1/index.html |
| dist.apache.org//repos/dist/dev/yetus/0.7.0-RC1/RELEASENOTES.md |
| dist.apache.org//repos/dist/dev/yetus/0.7.0-RC1/RELEASENOTES.md.asc |
| dist.apache.org//repos/dist/dev/yetus/0.7.0-RC1/RELEASENOTES.md.sha512 |
| dist.apache.org//repos/dist/dev/yetus/0.7.0-RC1/RELEASENOTES.md.mds |
| dist.apache.org//repos/dist/dev/yetus/0.7.0-RC1/apache-yetus-0.7.0-bin.tar.gz |
| dist.apache.org//repos/dist/dev/yetus/0.7.0-RC1/apache-yetus-0.7.0-bin.tar.gz.asc |
| dist.apache.org//repos/dist/dev/yetus/0.7.0-RC1/apache-yetus-0.7.0-bin.tar.gz.sha512 |
| dist.apache.org//repos/dist/dev/yetus/0.7.0-RC1/apache-yetus-0.7.0-bin.tar.gz.mds |
| dist.apache.org//repos/dist/dev/yetus/0.7.0-RC1/apache-yetus-0.7.0-src.tar.gz |
| dist.apache.org//repos/dist/dev/yetus/0.7.0-RC1/apache-yetus-0.7.0-src.tar.gz.asc |
| dist.apache.org//repos/dist/dev/yetus/0.7.0-RC1/apache-yetus-0.7.0-src.tar.gz.sha512 |
| dist.apache.org//repos/dist/dev/yetus/0.7.0-RC1/apache-yetus-0.7.0-src.tar.gz.mds |
| dist.apache.org//robots.txt |
| </code></pre></div> |
| <p>Lastly, if you haven't verified a release before, you'll need to download and import the public keys for the project's release managers. The public keys are located in the KEYS file that should have been mentioned in the [VOTE] thread announcement. The specific output of the following commands will vary depending on how many release managers there have been and which keys, if any, you have previously imported.</p> |
| |
| <div class="highlight"><pre class="highlight shell"><code><span class="nv">$ </span>curl <span class="nt">--output</span> KEYS.yetus <span class="nt">--silent</span> <span class="s1">'https://downloads.apache.org/yetus/KEYS'</span> |
| <span class="nv">$ </span>gpg <span class="nt">--import</span> KEYS.yetus |
| gpg: key 0D80DB7C: <span class="s2">"Sean Busbey (CODE SIGNING KEY) <busbey@apache.org>"</span> not changed |
| gpg: Total number processed: 1 |
| gpg: unchanged: 1 |
| </code></pre></div> |
| <h3 id="asf-required-checks">ASF required checks</h3> |
| |
| <p>ASF policies require that binding votes on releases be cast only after verifying proper licensing and provenance. For specific details, you should read the <a href="https://www.apache.org/dev/release.html#what-must-every-release-contain">ASF Release Policy's section entitled What Must Every ASF Release Contain?</a> as well as the informational page <a href="https://www.apache.org/info/verification.html">What We Sign</a>. The following is a non-normative set of guidelines.</p> |
| |
| <ol> |
| <li> |
| <p>You MUST make sure each of the signatures matches. As noted in the informational page <a href="https://www.apache.org/info/verification.html">What We Sign</a>, if you don't have the signer's key in your web of trust the output of the verify command will point this out. You should refer to it for guidance. For example, using gpg and taking a fictional source artifact:</p> |
| |
| <div class="highlight"><pre class="highlight shell"><code><span class="nv">$ </span><span class="nb">cd </span>dist.apache.org/repos/dist/dev/yetus/0.7.0-RC1/ |
| <span class="nv">$ </span>gpg <span class="nt">--verify</span> apache-yetus-0.7.0-src.tar.gz.asc apache-yetus-0.7.0-src.tar.gz |
| gpg: Signature made Fri Dec 11 11:50:56 2015 CST using RSA key ID 0D80DB7C |
| gpg: Good signature from <span class="s2">"Sean Busbey (CODE SIGNING KEY) <busbey@apache.org>"</span> |
| </code></pre></div> </li> |
| <li> |
| <p>You MUST make sure the provided hashes match the provided artifact.</p> |
| |
| <div class="highlight"><pre class="highlight shell"><code><span class="nv">$ </span>gpg <span class="nt">--print-mds</span> apache-yetus-0.7.0-src.tar.gz <span class="o">></span>apache-yetus-0.7.0-src.tar.gz.my_mds |
| <span class="nv">$ </span>diff apache-yetus-0.7.0-src.tar.gz.mds apache-yetus-0.7.0-src.tar.gz.my_mds |
| <span class="nv">$ </span>shasum <span class="nt">-a</span> 512 apache-yetus-0.7.0-src.tar.gz <span class="o">></span>apache-yetus-0.7.0-src.tar.gz.my_sha512 |
| <span class="nv">$ </span>diff apache-yetus-0.7.0-src.tar.gz.sha512 apache-yetus-0.7.0-src.tar.gz.my_sha512 |
| </code></pre></div> </li> |
| <li>You MUST make sure artifacts abide by the ASF Licensing Policy. You should read through <a href="https://www.apache.org/legal/resolved">the ASF Licensing Policy</a>, especially if your vote will be binding. As a quick guide: |
| <ul> |
| <li>Our software must be under the Apache Software License version 2.0 and this must be noted with a proper <code>LICENSE</code> and <code>NOTICE</code> file in each artifact that can hold them.</li> |
| <li>Our source code must meet the ASF policy on proper license notifications. Read the ASF Legal Committee's <a href="https://apache.org/legal/src-headers.html">Source Header Licensing Guide</a></li> |
| <li>Our <code>LICENSE</code> and <code>NOTICE</code> files must correctly propagate licensing information for bundled products. The <a href="https://www.apache.org/dev/licensing-howto.html">Foundation's Licensing HOWTO Guide</a> provides guidance on how these files should be maintained.</li> |
| <li>Our software must only bundle compatibly licensed products; read <a href="https://www.apache.org/legal/resolved#category-a">the Licensing Policy's Category A list for compatible licenses</a>.</li> |
| <li>Our software may only have a runtime dependency on a product with a prohibit license if its use is optional; read <a href="https://www.apache.org/legal/resolved#category-x">the Licensing Policy's Category X list for prohibited licenses</a> and <a href="https://www.apache.org/legal/resolved#optional">the Licensing Policy's explanation of optional runtime dependencies</a>.</li> |
| </ul> |
| </li> |
| <li> |
| <p>You SHOULD make sure the source release artifact corresponds to the referenced commit hash in the [VOTE] thread. A release tag that points to this commit hash is how we'll provide long-term provenance information for our downstream users. Since the release's source code artifact will be the canonical representation of the release we vote on, it is essential that it matches the contents of the version control system's tag. Given our example above, you can check this with recursive diff.</p> |
| |
| <p>NOTE: The <code>maven</code> plug-in that we use does not include some git control files like <code>.gitignore</code> and <code>.gitattributes</code>. Additionally, it adds a <code>DEPENDENCIES</code> file.</p> |
| |
| <div class="highlight"><pre class="highlight shell"><code><span class="nv">$ </span><span class="nb">mkdir </span>apache-yetus-0.7.0-src_unpack |
| <span class="nv">$ </span><span class="nb">tar</span> <span class="nt">-C</span> apache-yetus-0.7.0-src_unpack <span class="nt">-xzf</span> apache-yetus-0.7.0-src.tar.gz |
| <span class="nv">$ </span>git clone <span class="nt">--single-branch</span> <span class="nt">--depth</span><span class="o">=</span>1 <span class="nt">--branch</span> YETUS-585 <span class="s1">'https://github.com/apache/yetus.git'</span> apache-yetus-0.7.0-RC1-tag |
| <span class="nv">$ </span>git <span class="nt">--C</span> apache-yetus-0.7.0-RC1-tag show <span class="nt">-1</span> |
| .. verify the <span class="nb">hash</span> ... |
| <span class="nv">$ </span>diff <span class="nt">-r</span> apache-yetus-0.7.0-RC1-tag apache-yetus-0.7.0-src_unpack/apache-yetus-0.7.0 |
| </code></pre></div> </li> |
| <li> |
| <p>You MUST make sure any non-source artifacts can be derived from the source artifact. Since the source artifact is the canonical representation of our release, any other artifacts we distribute must be just for the convenience of our downstream users. As such, one must be able to derive them from the source artifact. Currently, you can generate all of the artifacts we distribute for convenience using the same commands used to create the release artifacts.</p> |
| |
| <div class="highlight"><pre class="highlight shell"><code><span class="nv">$ </span><span class="nb">mkdir </span>apache-yetus-0.7.0-src_unpack |
| <span class="nv">$ </span><span class="nb">tar</span> <span class="nt">-C</span> apache-yetus-0.7.0-src_unpack <span class="nt">-xzf</span> apache-yetus-0.7.0-src.tar.gz |
| <span class="nv">$ </span><span class="nb">cd </span>apache-yetus-0.7.0-src_unpack/apache-yetus-0.7.0 |
| <span class="nv">$ </span>mvn clean <span class="nb">install</span> |
| </code></pre></div> </li> |
| </ol> |
| |
| <p>This will create a <code>yetus-dist/target/</code> directory that contains the tarball binary distribution files.</p> |
| |
| <h3 id="community-recommended-checks">Community recommended checks</h3> |
| |
| <p>If you've gone through all of the ASF required checks, you'll already have made use of both the shelldocs and releasedocmaker components and confirmed that the compilable components successfully compile.</p> |
| |
| <ol> |
| <li> |
| <p>Test Precommit. The smart-apply-patch and test-patch scripts don't get flexed as a part of the above candidate verification. If you have a downstream project you regularly use, it should suffice to attempt local verification of a contribution. If that project happens to be an ASF project with an example personality, this should be as simple as finding an issue in patch-available status.</p> |
| |
| <div class="highlight"><pre class="highlight shell"><code> <span class="nv">$ </span><span class="nb">cd </span>path/to/my/repo/for/hbase |
| <span class="nv">$ </span>/some/path/to/the/unpacked/candidate/bin/test-patch <span class="nt">--project</span><span class="o">=</span>hbase HBASE-1772 |
| ...SNIP... |
| <span class="nt">-1</span> overall |
| |
| | Vote | Subsystem | Runtime | Comment |
| <span class="o">============================================================================</span> |
| | 0 | reexec | 0m 0s | Docker mode activated. |
| | +1 | hbaseanti | 0m 0s | Patch does not have any anti-patterns. |
| | +1 | @<span class="se">\a</span>uthor | 0m 0s | The patch does not contain any @<span class="se">\a</span>uthor |
| | | | | tags. |
| | +1 | test4tests | 0m 0s | The patch appears to include 2 new or |
| | | | | modified <span class="nb">test </span>files. |
| | +1 | mvninstall | 4m 41s | main passed |
| | +1 | compile | 1m 4s | main passed with JDK v1.8.0_72 |
| | +1 | compile | 0m 57s | main passed with JDK v1.7.0_95 |
| | +1 | checkstyle | 0m 36s | main passed |
| | +1 | mvneclipse | 0m 35s | main passed |
| | <span class="nt">-1</span> | findbugs | 1m 6s | hbase-client <span class="k">in </span>main has 19 extant |
| | | | | Findbugs warnings. |
| | <span class="nt">-1</span> | findbugs | 2m 8s | hbase-server <span class="k">in </span>main has 84 extant |
| | | | | Findbugs warnings. |
| | <span class="nt">-1</span> | javadoc | 0m 23s | hbase-client <span class="k">in </span>main failed with JDK |
| | | | | v1.8.0_72. |
| | <span class="nt">-1</span> | javadoc | 0m 34s | hbase-server <span class="k">in </span>main failed with JDK |
| | | | | v1.8.0_72. |
| | +1 | javadoc | 0m 57s | main passed with JDK v1.7.0_95 |
| | +1 | mvninstall | 1m 3s | the patch passed |
| | +1 | compile | 0m 59s | the patch passed with JDK v1.8.0_72 |
| | +1 | javac | 0m 59s | the patch passed |
| | +1 | compile | 0m 59s | the patch passed with JDK v1.7.0_95 |
| | +1 | javac | 0m 59s | the patch passed |
| | +1 | checkstyle | 0m 32s | the patch passed |
| | +1 | mvneclipse | 0m 28s | the patch passed |
| | +1 | whitespace | 0m 0s | Patch has no whitespace issues. |
| | +1 | hadoopcheck | 4m 28s | Patch does not cause any errors with |
| | | | | Hadoop 2.4.1 2.5.2 2.6.0. |
| | +1 | findbugs | 3m 37s | the patch passed |
| | <span class="nt">-1</span> | javadoc | 0m 24s | hbase-client <span class="k">in </span>the patch failed with |
| | | | | JDK v1.8.0_72. |
| | <span class="nt">-1</span> | javadoc | 0m 36s | hbase-server <span class="k">in </span>the patch failed with |
| | | | | JDK v1.8.0_72. |
| | +1 | javadoc | 1m 2s | the patch passed with JDK v1.7.0_95 |
| | +1 | unit | 1m 23s | hbase-client <span class="k">in </span>the patch passed with |
| | | | | JDK v1.8.0_72. |
| | <span class="nt">-1</span> | unit | 67m 12s | hbase-server <span class="k">in </span>the patch failed with |
| | | | | JDK v1.8.0_72. |
| | +1 | unit | 1m 28s | hbase-client <span class="k">in </span>the patch passed with |
| | | | | JDK v1.7.0_95. |
| | <span class="nt">-1</span> | unit | 66m 16s | hbase-server <span class="k">in </span>the patch failed with |
| | | | | JDK v1.7.0_95. |
| | +1 | asflicense | 0m 30s | Patch does not generate ASF License |
| | | | | warnings. |
| | | | 177m 13s | |
| |
| |
| Reason | Tests |
| JDK v1.8.0_72 Failed junit tests | hadoop.hbase.client.TestMultiParallel |
| JDK v1.7.0_95 Failed junit tests | hadoop.hbase.client.TestMultiParallel |
| |
| |
| <span class="o">||</span> Subsystem <span class="o">||</span> Report/Notes <span class="o">||</span> |
| <span class="o">============================================================================</span> |
| | Docker | <span class="nv">Client</span><span class="o">=</span>1.9.1 <span class="nv">Server</span><span class="o">=</span>1.9.1 Image:yetus/hbase:date2016-02-11 | |
| | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12787466/HBASE-1772.patch | |
| | JIRA Issue | HBASE-15198 | |
| | Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck hbaseanti checkstyle compile | |
| | <span class="nb">uname</span> | Linux 67e02eb9aeea 3.13.0-36-lowlatency <span class="c">#63-Ubuntu SMP PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |</span> |
| | Build tool | maven | |
| | Personality | /testptch/patchprocess/precommit/personality/hbase.sh | |
| | git revision | main / 81a6fff | |
| | findbugs | v2.0.1 | |
| | findbugs | /testptch/patchprocess/branch-findbugs-hbase-client-warnings.html | |
| | findbugs | /testptch/patchprocess/branch-findbugs-hbase-server-warnings.html | |
| | javadoc | /testptch/patchprocess/branch-javadoc-hbase-client-jdk1.8.0_72.txt | |
| | javadoc | /testptch/patchprocess/branch-javadoc-hbase-server-jdk1.8.0_72.txt | |
| | javadoc | /testptch/patchprocess/patch-javadoc-hbase-client-jdk1.8.0_72.txt | |
| | javadoc | /testptch/patchprocess/patch-javadoc-hbase-server-jdk1.8.0_72.txt | |
| | unit | /testptch/patchprocess/patch-unit-hbase-server-jdk1.8.0_72.txt | |
| | unit | /testptch/patchprocess/patch-unit-hbase-server-jdk1.7.0_95.txt | |
| | unit <span class="nb">test </span>logs | /testptch/patchprocess/patch-unit-hbase-server-jdk1.8.0_72.txt /testptch/patchprocess/patch-unit-hbase-server-jdk1.7.0_95.txt | |
| | modules | C: hbase-client hbase-server U: <span class="nb">.</span> | |
| | Powered by | Apache Yetus 0.7.0 http://yetus.apache.org | |
| </code></pre></div> </li> |
| <li> |
| <p>Test Audience Annotations. If you have a downstream project that relies on the audience annotations project, you should be able to install the jars locally and test with the updated version.</p> |
| |
| <div class="highlight"><pre class="highlight shell"><code> <span class="nv">$ </span><span class="nb">mkdir </span>apache-yetus-0.7.0-src_unpack |
| <span class="nv">$ </span><span class="nb">tar</span> <span class="nt">-C</span> apache-yetus-0.7.0-src_unpack <span class="nt">-xzf</span> apache-yetus-0.7.0-src.tar.gz |
| <span class="nv">$ </span><span class="nb">cd </span>apache-yetus-0.7.0-src_unpack/yetus-0.7.0 |
| <span class="nv">$ </span>mvn <span class="nt">--batch-mode</span> <span class="nb">install</span> |
| ...SNIP... |
| <span class="o">[</span>INFO] <span class="nt">------------------------------------------------------------------------</span> |
| <span class="o">[</span>INFO] BUILD SUCCESS |
| <span class="o">[</span>INFO] <span class="nt">------------------------------------------------------------------------</span> |
| <span class="o">[</span>INFO] Total <span class="nb">time</span>: 3.539 s |
| <span class="o">[</span>INFO] Finished at: 2016-02-13T02:12:39-06:00 |
| <span class="o">[</span>INFO] Final Memory: 14M/160M |
| <span class="o">[</span>INFO] <span class="nt">------------------------------------------------------------------------</span> |
| <span class="nv">$ </span><span class="nb">cd </span>path/to/your/project |
| <span class="nv">$ </span>vim pom.xml <span class="c"># edit version to be e.g. 0.7.0</span> |
| <span class="nv">$ </span>mvn verify |
| ...SNIP... |
| <span class="o">[</span>INFO] <span class="nt">------------------------------------------------------------------------</span> |
| <span class="o">[</span>INFO] BUILD SUCCESS |
| <span class="o">[</span>INFO] <span class="nt">------------------------------------------------------------------------</span> |
| <span class="o">[</span>INFO] Total <span class="nb">time</span>: 7.539 m |
| <span class="o">[</span>INFO] Finished at: 2016-02-13T02:13:39-06:00 |
| <span class="o">[</span>INFO] Final Memory: 14M/160M |
| <span class="o">[</span>INFO] <span class="nt">------------------------------------------------------------------------</span> |
| </code></pre></div> </li> |
| </ol> |
| |
| <h2 id="cleanup">Cleanup</h2> |
| |
| <p>Once a release candidate obtains majority approval from the PMC, there are several final maintenance tasks you must perform to close out the release.</p> |
| |
| <h3 id="core-release-tasks">Core Release Tasks</h3> |
| |
| <ol> |
| <li> |
| <p>Update the documentation in the git main branch for the new release. Remove the oldest release and add the latest.</p> |
| |
| <div class="highlight"><pre class="highlight shell"><code><span class="nv">$ </span>release/update-doc-versions.sh <span class="nt">--version</span><span class="o">=</span><x.y.z <span class="nt">--</span> version WITHOUT the rel/!> |
| <span class="nv">$ </span>git add <span class="nt">-p</span> |
| <span class="nv">$ </span>git add asf-site-src/data/versions.yml |
| <span class="nv">$ </span>git add asf-site-src/data/htaccess.yml |
| <span class="nv">$ </span>git commit |
| </code></pre></div> |
| <ul> |
| <li>Example commit message:</li> |
| </ul> |
| |
| <div class="highlight"><pre class="highlight plaintext"><code>YETUS-XXX. add release 0.7.0. |
| |
| - list in releases |
| - remove 0.4.0, add 0.7.0 to docs and downloads |
| </code></pre></div> </li> |
| <li>Commit the patch to the ASF source repo immediately, but do not update the website just yet.</li> |
| <li>Create shortcut links to the vote thread (e.g., <a href="https://s.apache.org/yetus-0.7.0-rc1-vote">https://s.apache.org/yetus-0.7.0-rc1-vote</a>) and the result (e.g., <a href="https://s.apache.org/yetus-0.7.0-vote-passes">https://s.apache.org/yetus-0.7.0-vote-passes</a>) that point to the archives on lists.apache.org. Be aware that it may take several hours for the archive to get the posts that need to be referenced.</li> |
| <li> |
| <p>Produce a signed release tag. You should create a signed tag and push it to the asf repo. The tag's message should include ASF-shortened links to the vote and results. It should be named 'rel/<em>version</em>' so that it will be immutable due to ASF infra's git configuration. Presuming we're working on the 0.7.0 release and the RC1 example above has passed:</p> |
| |
| <div class="highlight"><pre class="highlight plaintext"><code> $ git config --global user.signingkey <your-key-id> # if you've never configured |
| $ git tag --sign rel/0.7.0 1e8f4588906a51317207092bd97b35687f2e3fa3 Example commit message: |
| |
| YETUS-XXX. tag Apache Yetus 0.7.0 release. |
| |
| vote thread: https://s.apache.org/yetus-0.7.0-rc1-vote |
| |
| results: https://s.apache.org/yetus-0.7.0-vote-passes Then push: |
| |
| $ git push origin rel/0.7.0 |
| </code></pre></div> </li> |
| <li> |
| <p>Move release artifacts to the distribution area. The release officially happens once the artifacts are pushed to the ASF distribution servers. From this server, the artifacts will automatically be copied to the long-term archive as well as the various mirrors that will be used by downstream users. These must be <em>exactly</em> the artifacts from the RC that passed. Please note that currently, only Yetus PMC members have write access to this space. If you are not yet on the PMC, please ask the PMC to post the artifacts.</p> |
| |
| <div class="highlight"><pre class="highlight plaintext"><code> $ svn co https://dist.apache.org/repos/dist/release/yetus/ yetus-dist-release |
| $ cd yetus-dist-release |
| $ mkdir 0.7.0 |
| $ cp path/to/yetus-dist-dev/0.7.0-RC1/* 0.7.0 |
| $ svn add 0.7.0 |
| $ svn commit -m "Publish Apache Yetus 0.7.0" |
| </code></pre></div> </li> |
| <li>Add the release to the ASF reporter tool. To make our project reports for the ASF Board easier, you should include the release in the <a href="https://reporter.apache.org/addrelease.html?yetus">Apache Committee Report Helper website</a>. Be sure to use the date release artifacts first were pushed to the distribution area, which should be the same release date as in JIRA. Note that this website is only available to PMC members. If you are not yet in the PMC, please ask them to add the release information. Additionally, it will not let you set a future date.</li> |
| <li> |
| <p>Remove candidates from the staging area. Once you have moved the artifacts into the distribution area, they no longer need to be in the staging area and should be cleaned up as a courtesy to future release managers.</p> |
| |
| <div class="highlight"><pre class="highlight plaintext"><code> $ svn co https://dist.apache.org/repos/dist/dev/yetus/ yetus-dist-dev |
| $ cd yetus-dist-dev |
| $ svn rm 0.7.0-RC* |
| D 0.7.0-RC1/apache-yetus-0.7.0-src.tar.gz.sha512 |
| D 0.7.0-RC1/apache-yetus-0.7.0-bin.tar.gz.asc |
| D 0.7.0-RC1/RELEASENOTES.md |
| D 0.7.0-RC1/CHANGELOG.md.mds |
| D 0.7.0-RC1/CHANGELOG.md.sha512 |
| D 0.7.0-RC1/apache-yetus-0.7.0-src.tar.gz |
| D 0.7.0-RC1/RELEASENOTES.md.asc |
| D 0.7.0-RC1/apache-yetus-0.7.0-bin.tar.gz.mds |
| D 0.7.0-RC1/apache-yetus-0.7.0-bin.tar.gz.sha512 |
| D 0.7.0-RC1/apache-yetus-0.7.0-src.tar.gz.asc |
| D 0.7.0-RC1/CHANGELOG.md |
| D 0.7.0-RC1/RELEASENOTES.md.mds |
| D 0.7.0-RC1/CHANGELOG.md.asc |
| D 0.7.0-RC1/RELEASENOTES.md.sha512 |
| D 0.7.0-RC1/apache-yetus-0.7.0-bin.tar.gz |
| D 0.7.0-RC1/apache-yetus-0.7.0-src.tar.gz.mds |
| D 0.7.0-RC1 |
| $ svn commit -m "cleaning up release candidates from Apache Yetus 0.7.0 release process." |
| Deleting 0.7.0-RC1 |
| |
| Committed revision 1772. |
| </code></pre></div> </li> |
| <li>Resolve release issue; it should be marked as "fixed."</li> |
| <li>Go to the <a href="https://repository.apache.org/">ASF repository</a> and click 'Release' to put the RC Maven artifacts into the release repository.</li> |
| <li>Mark JIRA version as released. Browse to the <a href="https://issues.apache.org/jira/plugins/servlet/project-config/YETUS/versions">project version management page for the YETUS JIRA tracker</a>. Mouse over the version you are managing, click on the gear in the far right and select Release.</li> |
| <li>Delete staging branch. Now that there is an immutable tag for the release, all commits leading up to that release will be maintained by git. Should we need a future maintenance release after this version, we can reestablish the branch based off of the release tag.<br /> |
| $ git push origin :YETUS-XXX</li> |
| <li>Merge the release tag into main.</li> |
| <li>Merge in the <em>JIRA-main</em> PR that was created at the beginning of the release cycle.</li> |
| <li>Remove old releases from the distribution area. The ASF distribution area should only contain the most recent release for actively developed branches If your release is a maintenance release, delete the prior release. If your release marks the end of maintenance for an earlier minor or major release line, you should delete those versions from the distribution area.</li> |
| <li> |
| <p>Draft an announcement email. The announcement email should briefly describe our project and provide links to our artifacts and documentation. For example,<br /> |
| Subject: [ANNOUNCE] Apache Yetus 0.7.0 release</p> |
| |
| <div class="highlight"><pre class="highlight plaintext"><code> Apache Yetus 0.7.0 Released! |
| |
| The Apache Software Foundation and the Apache Yetus Project are pleased to |
| announce the release of version 0.7.0 of Apache Yetus. |
| |
| Apache Yetus is a collection of libraries and tools that enable contribution |
| and release processes for software projects. It provides a robust system |
| for automatically checking new contributions against a variety of community |
| accepted requirements, the means to document a well defined supported |
| interface for downstream projects, and tools to help release managers |
| generate release documentation based on the information provided by |
| community issue trackers and source repositories. |
| |
| |
| This version marks the latest minor release representing the community's |
| work over the last X months. |
| |
| |
| To download, please choose a mirror by visiting: |
| |
| https://yetus.apache.org/downloads/ |
| |
| The relevant checksums files are available at: |
| |
| https://downloads.apache.org/yetus/0.7.0/apache-yetus-0.7.0-src.tar.gz.sha512 |
| https://downloads.apache.org/yetus/0.7.0/apache-yetus-0.7.0-src.tar.gz.mds |
| https://downloads.apache.org/yetus/0.7.0/apache-yetus-0.7.0-bin.tar.gz.sha512 |
| https://downloads.apache.org/yetus/0.7.0/apache-yetus-0.7.0-bin.tar.gz.mds |
| |
| Project member signature keys can be found at |
| |
| https://downloads.apache.org/yetus/KEYS |
| |
| PGP signatures are available at: |
| |
| https://downloads.apache.org/yetus/0.7.0/apache-yetus-0.7.0-src.tar.gz.asc |
| https://downloads.apache.org/yetus/0.7.0/apache-yetus-0.7.0-bin.tar.gz.asc |
| |
| The list of changes included in this release and release notes can be browsed at: |
| |
| https://yetus.apache.org/documentation/0.7.0/CHANGELOG/ |
| https://yetus.apache.org/documentation/0.7.0/RELEASENOTES/ |
| |
| Documentation for this release is at: |
| |
| https://yetus.apache.org/documentation/0.7.0/ |
| |
| On behalf of the Apache Yetus team, thanks to everyone who helped with this |
| release! |
| |
| Questions, comments, and bug reports are always welcome on |
| |
| dev@yetus.apache.org |
| |
| -- |
| Meg Smith |
| Apache Yetus PMC If you'd like feedback on the draft, feel free to post it for review on your release issue. |
| </code></pre></div> </li> |
| <li>Wait an hour for the CDN to get properly updated before continuing.</li> |
| </ol> |
| |
| <h3 id="documentation">Documentation</h3> |
| |
| <ol> |
| <li>Publish website updates. See <a href="../website">Maintaining the Yetus Website</a>.</li> |
| <li>Verify that https://yetus.apache.org/latest.tgz and https://yetus.apache.org/latest.tgz.asc download the newly released version.</li> |
| </ol> |
| |
| <h3 id="homebrew">Homebrew</h3> |
| |
| <ol> |
| <li>Update the <code>yetus-homebrew</code> repo by using the release script. It will tag <em>and sign</em> (so GPG needs to work!) the top of the tree to point to the release. (Homebrew only uses top of tree, so branches are pointless.)</li> |
| </ol> |
| |
| <div class="highlight"><pre class="highlight shell"><code> <span class="nv">$ </span>./release.sh YETUS-XXX <x.y.z <span class="nt">--</span> version WITHOUT the rel/!> |
| </code></pre></div> |
| <ol> |
| <li>Test the formula:</li> |
| </ol> |
| |
| <div class="highlight"><pre class="highlight shell"><code> <span class="nv">$ </span><span class="c"># test the formula:</span> |
| <span class="nv">$ </span>brew <span class="nb">install</span> <span class="nt">--build-from-source</span> Formula/yetus.rb |
| <span class="c"># or if you already have it installed:</span> |
| <span class="nv">$ </span>brew upgrade <span class="nt">--build-from-source</span> Formula/yetus.rb |
| </code></pre></div> |
| <ol> |
| <li>If all looks good, push it live.</li> |
| </ol> |
| |
| <h3 id="github-marketplace-action">Github Marketplace Action</h3> |
| |
| <ol> |
| <li>Verify that the <a href="https://github.com/orgs/apache/packages?repo_name=yetus">Github Container Registry</a> has both repositories updated with the tagged release.</li> |
| <li>Update the <code>yetus-test-patch-action</code> repo by using the release script to create a branch which will then tag <em>and sign</em> (so GPG needs to work!) that branch:</li> |
| </ol> |
| |
| <div class="highlight"><pre class="highlight shell"><code> <span class="nv">$ </span>./release.sh YETUS-XXX <x.y.z <span class="nt">--</span> version WITHOUT the rel/!> |
| </code></pre></div> |
| <ol> |
| <li>Verify the branch and the tag match and that the container version matches the Apache Yetus release.</li> |
| <li>Push the branch:</li> |
| </ol> |
| |
| <div class="highlight"><pre class="highlight shell"><code> <span class="nv">$ </span>git push origin x.y.z |
| </code></pre></div> |
| <ol> |
| <li>Verify that the tag built in Github Actions.</li> |
| <li>Go to <a href="https://github.com/aw-was-here/yetus-test-patch-action/releases/new?marketplace=true">Draft a release</a></li> |
| <li>Type the tag that you just pushed into the 'tag' box.</li> |
| <li>Use categories 'Code Quality' 'Code Review'</li> |
| <li>Release Title should reflect the version</li> |
| <li>Describe this release should be a cut-down version of the announcement email (drop SHA and direct download links. main page, github actions, and release notes should be mentioned). See <a href="https://github.com/apache/yetus-test-patch-action/releases">Releases</a> for examples.</li> |
| <li>Mark 'This is a pre-release'</li> |
| <li>Verify everything looks good.</li> |
| <li>Publish release</li> |
| </ol> |
| |
| <h3 id="make-it-official">Make it Official</h3> |
| |
| <ol> |
| <li>Send announcement emails. The email should come from your apache.org email address and at a minimum should go to the dev@yetus.apache.org list. For details see <a href="https://www.apache.org/dev/release.html#release-announcements">the ASF Release Policy section How Should Releases Be Announced?</a>. Additionally, you may want to send the announcement to the development lists of downstream projects we know are using Yetus components.</li> |
| </ol> |
| |
| </div> |
| |
| <div class="container"> |
| <hr> |
| <footer class="footer"> |
| <div class="row-fluid"> |
| <div class="span12 text-left"> |
| <div class="span12"> |
| Copyright 2008-2023 <a href="https://www.apache.org/">Apache Software Foundation</a>. Licensed under the <a href="https://www.apache.org/licenses/">Apache License v2.0</a>. Apache Yetus and the Apache feather logo are trademarks of The Apache Software Foundation. |
| </div> |
| </div> |
| |
| </div> |
| |
| </footer> |
| </div> |
| |
| </body> |
| </html> |
