git hash 22aaadf10c4f9d22616612291a5a225641abf203
Project: http://git-wip-us.apache.org/repos/asf/yetus/repo Commit: http://git-wip-us.apache.org/repos/asf/yetus/commit/a22078fa Tree: http://git-wip-us.apache.org/repos/asf/yetus/tree/a22078fa Diff: http://git-wip-us.apache.org/repos/asf/yetus/diff/a22078fa Branch: refs/heads/asf-site Commit: a22078fa46e2470efeb84994762a57ee88c4df2b Parents: 360ba08 Author: Allen Wittenauer <[email protected]> Authored: Fri Nov 30 09:26:35 2018 -0800 Committer: Allen Wittenauer <[email protected]> Committed: Fri Nov 30 09:26:35 2018 -0800 ---------------------------------------------------------------------- LICENSE | 86 ++++ NOTICE | 2 +- README.md | 65 +++ contribute/releases/index.html | 435 +++++++++---------- contribute/website/index.html | 42 +- css/maven-base.css | 168 +++++++ css/maven-theme.css | 161 +++++++ css/print.css | 26 ++ css/site.css | 1 + .../allclasses-frame.html | 4 +- .../allclasses-noframe.html | 4 +- .../constant-values.html | 4 +- .../deprecated-list.html | 4 +- .../audience-annotations-apidocs/help-doc.html | 4 +- .../audience-annotations-apidocs/index-all.html | 4 +- .../audience-annotations-apidocs/index.html | 2 +- .../InterfaceAudience.LimitedPrivate.html | 4 +- .../audience/InterfaceAudience.Private.html | 4 +- .../audience/InterfaceAudience.Public.html | 4 +- .../yetus/audience/InterfaceAudience.html | 4 +- .../audience/InterfaceStability.Evolving.html | 4 +- .../audience/InterfaceStability.Stable.html | 4 +- .../audience/InterfaceStability.Unstable.html | 4 +- .../yetus/audience/InterfaceStability.html | 4 +- .../InterfaceAudience.LimitedPrivate.html | 4 +- .../class-use/InterfaceAudience.Private.html | 4 +- .../class-use/InterfaceAudience.Public.html | 4 +- .../audience/class-use/InterfaceAudience.html | 4 +- .../class-use/InterfaceStability.Evolving.html | 4 +- .../class-use/InterfaceStability.Stable.html | 4 +- .../class-use/InterfaceStability.Unstable.html | 4 +- .../audience/class-use/InterfaceStability.html | 4 +- .../apache/yetus/audience/package-frame.html | 4 +- .../apache/yetus/audience/package-summary.html | 4 +- .../org/apache/yetus/audience/package-tree.html | 4 +- .../org/apache/yetus/audience/package-use.html | 4 +- .../ExcludePrivateAnnotationsJDiffDoclet.html | 4 +- ...ExcludePrivateAnnotationsStandardDoclet.html | 4 +- .../IncludePublicAnnotationsStandardDoclet.html | 4 +- .../ExcludePrivateAnnotationsJDiffDoclet.html | 4 +- ...ExcludePrivateAnnotationsStandardDoclet.html | 4 +- .../IncludePublicAnnotationsStandardDoclet.html | 4 +- .../yetus/audience/tools/package-frame.html | 4 +- .../yetus/audience/tools/package-summary.html | 4 +- .../yetus/audience/tools/package-tree.html | 4 +- .../yetus/audience/tools/package-use.html | 4 +- .../overview-frame.html | 4 +- .../overview-summary.html | 4 +- .../overview-tree.html | 4 +- .../allclasses-frame.html | 4 +- .../allclasses-noframe.html | 4 +- .../constant-values.html | 4 +- .../deprecated-list.html | 4 +- .../audience-annotations-apidocs/help-doc.html | 4 +- .../audience-annotations-apidocs/index-all.html | 4 +- .../audience-annotations-apidocs/index.html | 2 +- .../InterfaceAudience.LimitedPrivate.html | 4 +- .../audience/InterfaceAudience.Private.html | 4 +- .../audience/InterfaceAudience.Public.html | 4 +- .../yetus/audience/InterfaceAudience.html | 4 +- .../audience/InterfaceStability.Evolving.html | 4 +- .../audience/InterfaceStability.Stable.html | 4 +- .../audience/InterfaceStability.Unstable.html | 4 +- .../yetus/audience/InterfaceStability.html | 4 +- .../InterfaceAudience.LimitedPrivate.html | 4 +- .../class-use/InterfaceAudience.Private.html | 4 +- .../class-use/InterfaceAudience.Public.html | 4 +- .../audience/class-use/InterfaceAudience.html | 4 +- .../class-use/InterfaceStability.Evolving.html | 4 +- .../class-use/InterfaceStability.Stable.html | 4 +- .../class-use/InterfaceStability.Unstable.html | 4 +- .../audience/class-use/InterfaceStability.html | 4 +- .../apache/yetus/audience/package-frame.html | 4 +- .../apache/yetus/audience/package-summary.html | 4 +- .../org/apache/yetus/audience/package-tree.html | 4 +- .../org/apache/yetus/audience/package-use.html | 4 +- .../ExcludePrivateAnnotationsJDiffDoclet.html | 4 +- ...ExcludePrivateAnnotationsStandardDoclet.html | 4 +- .../IncludePublicAnnotationsStandardDoclet.html | 4 +- .../ExcludePrivateAnnotationsJDiffDoclet.html | 4 +- ...ExcludePrivateAnnotationsStandardDoclet.html | 4 +- .../IncludePublicAnnotationsStandardDoclet.html | 4 +- .../yetus/audience/tools/package-frame.html | 4 +- .../yetus/audience/tools/package-summary.html | 4 +- .../yetus/audience/tools/package-tree.html | 4 +- .../yetus/audience/tools/package-use.html | 4 +- .../overview-frame.html | 4 +- .../overview-summary.html | 4 +- .../overview-tree.html | 4 +- .../0.7.0/precommit-apidocs/core/index.html | 60 ++- .../allclasses-frame.html | 4 +- .../allclasses-noframe.html | 4 +- .../constant-values.html | 4 +- .../deprecated-list.html | 4 +- .../audience-annotations-apidocs/help-doc.html | 4 +- .../audience-annotations-apidocs/index-all.html | 4 +- .../audience-annotations-apidocs/index.html | 2 +- .../InterfaceAudience.LimitedPrivate.html | 4 +- .../audience/InterfaceAudience.Private.html | 4 +- .../audience/InterfaceAudience.Public.html | 4 +- .../yetus/audience/InterfaceAudience.html | 4 +- .../audience/InterfaceStability.Evolving.html | 4 +- .../audience/InterfaceStability.Stable.html | 4 +- .../audience/InterfaceStability.Unstable.html | 4 +- .../yetus/audience/InterfaceStability.html | 4 +- .../InterfaceAudience.LimitedPrivate.html | 4 +- .../class-use/InterfaceAudience.Private.html | 4 +- .../class-use/InterfaceAudience.Public.html | 4 +- .../audience/class-use/InterfaceAudience.html | 4 +- .../class-use/InterfaceStability.Evolving.html | 4 +- .../class-use/InterfaceStability.Stable.html | 4 +- .../class-use/InterfaceStability.Unstable.html | 4 +- .../audience/class-use/InterfaceStability.html | 4 +- .../apache/yetus/audience/package-frame.html | 4 +- .../apache/yetus/audience/package-summary.html | 4 +- .../org/apache/yetus/audience/package-tree.html | 4 +- .../org/apache/yetus/audience/package-use.html | 4 +- .../ExcludePrivateAnnotationsJDiffDoclet.html | 4 +- ...ExcludePrivateAnnotationsStandardDoclet.html | 4 +- .../IncludePublicAnnotationsStandardDoclet.html | 4 +- .../ExcludePrivateAnnotationsJDiffDoclet.html | 4 +- ...ExcludePrivateAnnotationsStandardDoclet.html | 4 +- .../IncludePublicAnnotationsStandardDoclet.html | 4 +- .../yetus/audience/tools/package-frame.html | 4 +- .../yetus/audience/tools/package-summary.html | 4 +- .../yetus/audience/tools/package-tree.html | 4 +- .../yetus/audience/tools/package-use.html | 4 +- .../overview-frame.html | 4 +- .../overview-summary.html | 4 +- .../overview-tree.html | 4 +- .../0.8.0/precommit-apidocs/core/index.html | 60 ++- .../0.8.0/precommit-apidocs/plugins/index.html | 112 +++-- documentation/in-progress/CHANGELOG/index.html | 279 ++++++++++++ .../in-progress/RELEASENOTES/index.html | 183 ++++++++ .../css/maven-base.css | 168 +++++++ .../css/maven-theme.css | 161 +++++++ .../audience-annotations-apidocs/css/print.css | 26 ++ .../audience-annotations-apidocs/css/site.css | 1 + .../images/collapsed.gif | Bin 0 -> 53 bytes .../images/expanded.gif | Bin 0 -> 52 bytes .../images/external.png | Bin 0 -> 230 bytes .../images/icon_error_sml.gif | Bin 0 -> 1010 bytes .../images/icon_info_sml.gif | Bin 0 -> 606 bytes .../images/icon_success_sml.gif | Bin 0 -> 990 bytes .../images/icon_warning_sml.gif | Bin 0 -> 576 bytes .../images/logos/build-by-maven-black.png | Bin 0 -> 2294 bytes .../images/logos/build-by-maven-white.png | Bin 0 -> 2260 bytes .../images/logos/maven-feather.png | Bin 0 -> 3330 bytes .../images/newwindow.png | Bin 0 -> 220 bytes .../in-progress/precommit-buildtools/index.html | 2 +- images/collapsed.gif | Bin 0 -> 53 bytes images/expanded.gif | Bin 0 -> 52 bytes images/external.png | Bin 0 -> 230 bytes images/icon_error_sml.gif | Bin 0 -> 1010 bytes images/icon_info_sml.gif | Bin 0 -> 606 bytes images/icon_success_sml.gif | Bin 0 -> 990 bytes images/icon_warning_sml.gif | Bin 0 -> 576 bytes images/logos/build-by-maven-black.png | Bin 0 -> 2294 bytes images/logos/build-by-maven-white.png | Bin 0 -> 2260 bytes images/logos/maven-feather.png | Bin 0 -> 3330 bytes images/newwindow.png | Bin 0 -> 220 bytes 161 files changed, 1896 insertions(+), 616 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/yetus/blob/a22078fa/LICENSE ---------------------------------------------------------------------- diff --git a/LICENSE b/LICENSE index 5e115b3..21579c4 100644 --- a/LICENSE +++ b/LICENSE @@ -385,3 +385,89 @@ OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. ---- + +This project incorporates via jQuery portions of the Sizzle project +available under the MIT license: + +Copyright JS Foundation and other contributors, https://js.foundation/ + +This software consists of voluntary contributions made by many +individuals. For exact contribution history, see the revision history +available at https://github.com/jquery/sizzle + +The following license applies to all parts of this software except as +documented below: + +==== + +Permission is hereby granted, free of charge, to any person obtaining +a copy of this software and associated documentation files (the +"Software"), to deal in the Software without restriction, including +without limitation the rights to use, copy, modify, merge, publish, +distribute, sublicense, and/or sell copies of the Software, and to +permit persons to whom the Software is furnished to do so, subject to +the following conditions: + +The above copyright notice and this permission notice shall be +included in all copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, +EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF +MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND +NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE +LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION +OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION +WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. + +---- + +This project utilizes Jython 2.7 for running Python code on JVMs. It +is available under the Python Software Foundation License v2: + +PYTHON SOFTWARE FOUNDATION LICENSE VERSION 2 +-------------------------------------------- + +1. This LICENSE AGREEMENT is between the Python Software Foundation +("PSF"), and the Individual or Organization ("Licensee") accessing and +otherwise using this software ("Jython") in source or binary form and +its associated documentation. + +2. Subject to the terms and conditions of this License Agreement, PSF +hereby grants Licensee a nonexclusive, royalty-free, world-wide +license to reproduce, analyze, test, perform and/or display publicly, +prepare derivative works, distribute, and otherwise use Jython alone +or in any derivative version, provided, however, that PSF's License +Agreement and PSF's notice of copyright, i.e., "Copyright (c) 2007 +Python Software Foundation; All Rights Reserved" are retained in +Jython alone or in any derivative version prepared by Licensee. + +3. In the event Licensee prepares a derivative work that is based on +or incorporates Jython or any part thereof, and wants to make +the derivative work available to others as provided herein, then +Licensee hereby agrees to include in any such work a brief summary of +the changes made to Jython. + +4. PSF is making Jython available to Licensee on an "AS IS" +basis. PSF MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR +IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, PSF MAKES NO AND +DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS +FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF JYTHON WILL NOT +INFRINGE ANY THIRD PARTY RIGHTS. + +5. PSF SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF JYTHON +FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS +A RESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE USING JYTHON, +OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF. + +6. This License Agreement will automatically terminate upon a material +breach of its terms and conditions. + +7. Nothing in this License Agreement shall be deemed to create any +relationship of agency, partnership, or joint venture between PSF and +Licensee. This License Agreement does not grant permission to use PSF +trademarks or trade name in a trademark sense to endorse or promote +products or services of Licensee, or any third party. + +8. By copying, installing or otherwise using Jython, Licensee +agrees to be bound by the terms and conditions of this License +Agreement. http://git-wip-us.apache.org/repos/asf/yetus/blob/a22078fa/NOTICE ---------------------------------------------------------------------- diff --git a/NOTICE b/NOTICE index 73e26b4..5cb4db8 100644 --- a/NOTICE +++ b/NOTICE @@ -1,5 +1,5 @@ Apache Yetus -Copyright 2008-2016 The Apache Software Foundation +Copyright 2008-2018 The Apache Software Foundation This product includes software developed at The Apache Software Foundation (http://www.apache.org/). http://git-wip-us.apache.org/repos/asf/yetus/blob/a22078fa/README.md ---------------------------------------------------------------------- diff --git a/README.md b/README.md new file mode 100644 index 0000000..a7dde39 --- /dev/null +++ b/README.md @@ -0,0 +1,65 @@ +<!--- + 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. +--> +# Apache Yetus + +Apache Yetus is a collection of libraries and tools that enable +contribution and release process for software projects. + +## Components + +Here is a list of the major components: + +* [Website source](asf-site-src/) +Holds our documentation, which is presented via [our website](https://yetus.apache.org/). +* [Precommit](precommit/) +Precommit provides robust tools to deal with contributions, including applying patches from a variety of project sources and evaluating them against project norms via a system of plugins. See the [precommit overview](asf-site-src/source/documentation/in-progress/precommit-architecture.md) to get started working with precommit. +* [Audience Annotations](audience-annotations-component/) +Audience Annotations allows projects to use Java Annotations to delineate public and non-public parts of their APIs. It also provides doclets to generate javadocs filtered by the intended audience. Currently builds with Maven 3.2.0+. +* [Shelldocs](shelldocs/) +Shelldocs processes comments on Bash functions for annotations similar to Javadoc. It also includes built-in audience scoping functionality similar to the doclet from Audience Annotations. +* [Release Doc Maker](release-doc-maker/) +Release Doc Maker analyzes Jira and Git information to produce Markdown formatted release notes. +* [yetus-maven-plugin](yetus-maven-plugin/) +Builds a maven plugin that provides some small utilities for some uncommon maven requirements (such as symlinks) in addition to being mavenized versions of some of the Apache Yetus functionality. + +## Building Quickstart + +For full instructions on how to build releases and the website, see the [guide to contributing](asf-site-src/source/contribute.html.md) for requirements and instructions. + +```bash +# Launch a Docker container that has all of the project's dependencies and a working build environment +./start-build-env.sh + +# Build the binary tarball, located in yetus-dist/target/artifacts: +mvn clean install + +# Build the binary and source tarballs and sign the content: +mvn clean install -Papache-release + +# Same, but if outside the container and need to let the system know that the OS uses 'gpg2' instead of 'gpg': +mvn clean install -Papache-release -Pgpg2 + +# Build the binary and source tarballs, but skip signing them: +mvn clean install -Papache-release -Dgpg.sign=skip + +# Build the website (requires a mvn install first) +mvn site +``` + +After executing one or more of the Apache Maven commands, artifacts will be in `yetus-dist/target/artifacts` or ready for a `mvn deploy`. \ No newline at end of file http://git-wip-us.apache.org/repos/asf/yetus/blob/a22078fa/contribute/releases/index.html ---------------------------------------------------------------------- diff --git a/contribute/releases/index.html b/contribute/releases/index.html index ca5ec39..1aa33a0 100644 --- a/contribute/releases/index.html +++ b/contribute/releases/index.html @@ -122,7 +122,7 @@ <h1 id="managing-a-release">Managing a Release</h1> -<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 supercede foundation policy should the two disagree.</p> +<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> @@ -130,7 +130,7 @@ <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="http://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 commiters have write access to</a>.</p> +<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> @@ -138,35 +138,37 @@ <h3 id="cryptographic-signing-tools-and-keys">Cryptographic Signing Tools and Keys</h3> -<p>Everything distributed by an ASF project must be signed prior to 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>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 a good 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> +<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 Subversion installation. This is because both the staging area for release candidates and the final distribution mechanism for PMC approved releases rely on Subversion.</p> +<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="http://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="http://subversion.apache.org/download.cgi";>Apache Subversion - Download Source Code</a>.</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, you’ll need to build both our project docs and all of individual components. If you normally only work on one part of the project, say Yetus Precommit, this might require some additional programming languages and tools.</p> +<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. If you usually only work on one part of the project, say Yetus Precommit, this might require some additional programming languages and tools.</p> + +<p>All of these tools should be in the Docker container that is launched by using the <code>./start-build-dev.sh</code> script. If you wish to build outside of the container (not recommended), you will need:</p> <ul> -<li>Yetus Audience Annotations will require Maven 3.2.0+ and Java 7.</li> -<li>Yetus Precommit will require Python 2.6+ for generating documentation on its API via Yetus Shelldocs.</li> -<li>The project documentation will require Ruby 2.x+ for rendering.</li> -<li>We’ll build release notes with Yetus Release Doc Maker, which will require Python 2.6+.</li> -<li>Assembling release artifacts will make use of bash, tar, gzip, and shasum.</li> +<li>Maven 3.2.0+</li> +<li>Java 8</li> +<li>Python 2.7</li> +<li>Ruby 2.x+</li> +<li>bash, tar, gzip, gpg, and shasum</li> </ul> <h2 id="setup">Setup</h2> -<p>When you first start managing a given release you’ll have to take care of the following tasks. With the exception of creating the release staging branch, these can be done in any order.</p> +<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="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="http://www.apache.org/dist/yetus/KEYS";>http://www.apache.org/dist/yetus/KEYS</a>. You can read about this file in the ASF guide to release signing’s section <a href="http://www.apache.org/dist/yetus/KEYS";>The KEYS File</a>. If your public key is not already included in this file, 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 commiting.</p> +<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://www.apache.org/dist/yetus/KEYS";>https://www.apache.org/dist/yetus/KEYS</a>. You can read about this file in the ASF guide to release signing’s section <a href="https://www.apache.org/dist/yetus/KEYS";>The KEYS File</a>. If your public key is not already included in this file, 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 plaintext"><code>$ svn co https://dist.apache.org/repos/dist/release/yetus yetus-dist-release @@ -185,42 +187,43 @@ $ svn commit -m "Added myself to KEYS." <li>On the next screen, use a subject line like <q>Release VERSION</q>, with an appropriate version number. Fill in the following fields and click <q>Create</q>. <ul> -<li>Component should be <q>website and documentation</q></li> +<li>The component should be <q>website and documentation</q></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 <q>Generate release candidates as needed to create a VERSION release.</q> with an appropriate version number.</li> </ul></li> </ol> -<p>Next, create a shortened link to the JIRA version’s release notes. This should use the ASF link shortener, <a href="http://s.apache.org/";>http://s.apache.org/</a>. To find the appropriate release notes page:</p> +<p>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:</p> <ol> <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 <q>Release Notes</q> button. If it isn’t shown, click on the <q>Summary</q> button in the left menu</li> <li>Copy this URL</li> -<li>Browse to the ASF URL shortener: <a href="http://s.apache.org/";>http://s.apache.org/</a></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 <q>URI</q> field</li> <li>Set the optional key field to ‘yetus-<em>version</em>-jira’</li> </ol> -<p>For example, on the 0.2.0 release you would use ‘<a href="https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318920&version=12334330";>https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318920&version=12334330</a>’ for the URI field and 'yetus-0.2.0-jira’ for the key.</p> +<p>For example, on the 0.7.0 release, you would use ‘<a href="https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318920&version=12334330";>https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318920&version=12334330</a>’ for the URI field and 'yetus-0.7.0-jira’ for the key.</p> -<p>Finally, you should create a JIRA version to correspond to the release <em>following</em> the one you are managing. This is so that folks can continue to work on things that won’t make it into the in-progress release while we evaluate candidates.</p> +<p>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.</p> <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.2.0 release, fill in 0.3.0.</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.3.0.</li> <li>Set a start date of today.</li> <li>Click <q>Add</q></li> </ol> <h3 id="work-in-git">Work in Git</h3> -<p>Once you have a issue to track things, you can create the git branch for staging our release. This seperate branch will allow you to polish the release while regular work continues on the master branch. You will need to update master for the next SNAPSHOT version and the branch for the release.</p> +<p>Once you have an issue to track things, you can create the git branch for staging our release. This separate branch will allow you to polish the release while regular work continues on the master branch. You will need to update master for the next SNAPSHOT version and the branch for the release.</p> -<p>Example commands, presuming the release under management is <strong>0.2.0</strong> and the JIRA issue is <strong>YETUS-XXX</strong>:</p> +<p>Example commands, presuming the release under management is <strong>0.7.0</strong> and the JIRA issue is <strong>YETUS-XXX</strong>:</p> <div class="highlight"><pre class="highlight plaintext"><code>$ # Ensure master is up to date +$ mvn clean $ git fetch origin $ git status # On branch master @@ -233,53 +236,72 @@ Fast-forwarded master to origin/master. $ git status # On branch master nothing to commit (working directory clean) -$ # create branch and push without changes +$ # create a branch and push without changes $ git checkout -b YETUS-XXX Switched to a new branch 'YETUS-XXX' $ git push origin YETUS-XXX $ # find files we need to update for release -$ grep -rl "0.2.0-SNAPSHOT" * 2>/dev/null -VERSION +$ grep -rl "0.7.0-SNAPSHOT" * 2>/dev/null +asf-site-src/pom.xml audience-annotations-component/audience-annotations/pom.xml audience-annotations-component/audience-annotations-jdiff/pom.xml audience-annotations-component/pom.xml -yetus-project/pom.xml +pom.xml +precommit/pom.xml +releasedocmaker/pom.xml +shelldocs/pom.xml +yetus-dist/pom.xml +yetus-maven-plugin/pom.xml +yetus-minimaven-plugin/pom.xml +</code></pre></div> +<p>At this point, you should edit the files mentioned above. They must have the version we expect upon a successful release. Search for instances of <em>VERSION-SNAPSHOT</em> and replace with <em>VERSION</em>; e.g., <em>0.7.0-SNAPSHOT</em> should become <em>0.7.0</em>:</p> +<div class="highlight"><pre class="highlight plaintext"><code>$ perl -pi -e 's,0.7.0-SNAPSHOT,0.7.0,g' $(find . -type f) </code></pre></div> -<p>At this point you should edit the aforementioned files so they have the version we expect upon a successful release. Search for instances of <em>VERSION-SNAPSHOT</em> and replace with <em>VERSION</em>; e.g. <em>0.2.0-SNAPSHOT</em> should become <em>0.2.0</em>. After you are done, create a branch-specific patch and then prepare to update the master branch.</p> +<p>After you are done, create a branch-specific patch and then prepare to update the master branch.</p> <div class="highlight"><pre class="highlight plaintext"><code>$ git add -p -$ git commit -m "YETUS-XXX. Stage version 0.2.0." +$ git commit -m "YETUS-XXX. Stage version 0.7.0." $ git format-patch --stdout origin/YETUS-XXX > path/to/patches/YETUS-XXX-YETUS-XXX.1.patch $ git checkout master -$ grep -rl "0.2.0-SNAPSHOT" * 2>/dev/null -VERSION +$ grep -rl "0.7.0-SNAPSHOT" * 2>/dev/null +asf-site-src/pom.xml audience-annotations-component/audience-annotations/pom.xml audience-annotations-component/audience-annotations-jdiff/pom.xml audience-annotations-component/pom.xml -yetus-project/pom.xml +pom.xml +precommit/pom.xml +releasedocmaker/pom.xml +shelldocs/pom.xml +yetus-dist/pom.xml +yetus-maven-plugin/pom.xml +yetus-minimaven-plugin/pom.xml </code></pre></div> -<p>Now update these files, but this time you should update them for the next minor version’s SNAPSHOT. e.g. <em>0.2.0-SNAPSHOT</em> should become <em>0.3.0-SNAPSHOT</em>. After you are done, create a patch.</p> +<p>Now update these files, but this time you should update them for the next minor version’s SNAPSHOT. e.g., <em>0.7.0-SNAPSHOT</em> should become <em>0.8.0-SNAPSHOT</em>:</p> +<div class="highlight"><pre class="highlight plaintext"><code>$ perl -pi -e 's,0.7.0-SNAPSHOT,0.8.0,g' $(find . -type f) +</code></pre></div> +<p>After you are done, create a patch.</p> <div class="highlight"><pre class="highlight plaintext"><code>$ git add -p -$ git commit -m "YETUS-XXX. bump master version to 0.3.0-SNAPSHOT" +$ git commit -m "YETUS-XXX. bump master version to 0.8.0-SNAPSHOT" $ git format-patch --stdout origin/master > path/to/patches/YETUS-XXX.1.patch </code></pre></div> -<p>Both of these patch files should be uploaded to your release issue for review. Once the patches get approval push them to the repository.</p> +<p>Both of these patch files should be uploaded to your release issue for review. Push them to the repository once the patches get approval.</p> <h2 id="release-candidate-s">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>) and set the release date to when you expect your next vote thread to close. This date will be used by our generated release notes.</li> -<li>Update your <code>${HOME}/.m2/settings.xml</code> file to include the Maven snapshot information as indicated on <a href="http://www.apache.org/dev/publishing-maven-artifacts.html";>http://www.apache.org/dev/publishing-maven-artifacts.html</a></li> +<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>) and set the release date to when you expect your next vote thread to close. Our generated release notes will use this date.</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. You should use our convenience script to create the tarballs and markdown documents for a release. Run the following from the release staging branch and inspect the results:</p> -<div class="highlight"><pre class="highlight plaintext"><code>$ ./build.sh --release --deploy -$ ls -lah target/RELEASENOTES.md target/CHANGELOG.md target/*.tar.gz +<div class="highlight"><pre class="highlight plaintext"><code>$ mvn --batch-mode clean install -Papache-release +$ mvn --batch-mode site +$ ls -lah yetus-dist/target/artifacts/* </code></pre></div></li> -<li><p>Check out the staging area for release candidates and make a directory for this candidate, somewhere outside of the your working directory. Copy the artifacts from the previous step into place. For example, when working on RC1 for the 0.2.0 release</p> +<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 (<strong>except for the site.tar.gz</strong>) 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 plaintext"><code>$ svn co https://dist.apache.org/repos/dist/dev/yetus/ yetus-dist-dev $ cd yetus-dist-dev -$ mkdir 0.2.0-RC1 -$ cd 0.2.0-RC1 +$ mkdir 0.7.0-RC1 +$ cd 0.7.0-RC1 $ cp path/to/yetus/target/RELEASENOTES.md path/to/yetus/target/CHANGELOG.md path/to/yetus/target/*.tar.gz . </code></pre></div></li> <li><p>While still in the staging area, sign the artifacts and create the needed checksum files:</p> @@ -292,45 +314,45 @@ $ cp path/to/yetus/target/RELEASENOTES.md path/to/yetus/target/CHANGELOG.md path </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 plaintext"><code>$ cd .. -$ svn add 0.2.0-RC1 -$ svn commit -m "stage Apache Yetus 0.2.0-RC1" +$ svn add 0.7.0-RC1 +$ svn commit -m "stage Apache Yetus 0.7.0-RC1" </code></pre></div> -<p>Afterwards, the artifacts should be visible via the web under the same URL used when checking out. In the case of 0.2.0-RC1: <a href="https://dist.apache.org/repos/dist/dev/yetus/0.2.0-RC1/";>https://dist.apache.org/repos/dist/dev/yetus/0.2.0-RC1/</a></p></li> -<li><p>Examine staged maven build. Go to the <a href="http://repository.apache.org/";>ASF repository</a> and log in with your asf LDAP credentials. Look for the staging repository with a name that includes <q>yetus</q>. Clicking on it will give you a link to an <q>Open</q> repository. You can examine the structure in the Nexus API while you’re logged in. If it looks essentially correct, <q>Close</q> 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.</p></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 <q>[VOTE]</q> 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.2.0-RC1, update it as appropriate for your release:</p> -<div class="highlight"><pre class="highlight plaintext"><code>Subject: [VOTE] Apache Yetus 0.2.0-RC1 +<p>Afterward, the artifacts should be visible via the web under the same URL used when checking out. In the case of 0.7.0-RC1: <a href="https://dist.apache.org/repos/dist/dev/yetus/0.7.0-RC1/";>https://dist.apache.org/repos/dist/dev/yetus/0.7.0-RC1/</a></p></li> +<li><p>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 <q>yetus</q>. Clicking on it will give you a link to an <q>Open</q> repository. You can examine the structure in the Nexus API while you’re logged in. If it looks essentially correct, <q>Close</q> 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.</p></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 <q>[VOTE]</q> 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.2.0-RC1/ +https://dist.apache.org/repos/dist/dev/yetus/0.7.0-RC1/ As of this vote the relevant sha512 hashes are: -SHA512 (CHANGELOG.md) = b7f7894d686a59aad1a4afe2ae8fbb94 -SHA512 (RELEASENOTES.md) = e321ef2909e3e51ce40bbf701159b01e -SHA512 (yetus-0.2.0-bin.tar.gz) = e23fe4d34611a4c027df3f515cb46d7e -SHA512 (yetus-0.2.0-src.tar.gz) = e57b96533092356f3d5b9b4f47654fe9 +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://dist.apache.org/repos/dist/release/yetus/KEYS +Our KEYS file is at: https://www.apache.org/dist/yetus/KEYS All artifacts are signed with my key (DEADBEEF) -JIRA version: http://s.apache.org/yetus-0.2.0-jira +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.2.0 +[ ] +1 Release this package as Apache Yetus 0.7.0 [ ] +0 no opinion [ ] -1 Do not release this package because... -Vote will be subject to Majority Approval[2] and will close at 8:00PM -UTC on Monday, Xxx XXth, 2016[3]. +The vote will be subject to Majority Approval[2] and will close at 8:00 PM +UTC on Monday, Xxx XXth, 2018[3]. -[1]: http://www.apache.org/info/verification.html +[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: -http://s.apache.org/yetus-0.2.0-rc1-close +https://s.apache.org/yetus-0.7.0-rc1-close </code></pre></div> <p>That final short link should point to some online timezone conversion utility. ASF votes often use timeanddate.com’s Event Time Announcer: <a href="http://www.timeanddate.com/worldclock/fixedform.html";>http://www.timeanddate.com/worldclock/fixedform.html</a>.</p></li> <li><p>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 <q>[RESULT]</q>. 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></p></li> @@ -338,35 +360,36 @@ http://s.apache.org/yetus-0.2.0-rc1-close <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 suites you.</p> +<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 plaintext"><code>$ wget --recursive --no-parent --quiet 'https://dist.apache.org/repos/dist/dev/yetus/0.2.0-RC1/' +<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 plaintext"><code>$ wget --recursive --no-parent --quiet 'https://dist.apache.org/repos/dist/dev/yetus/0.7.0-RC1/' $ find dist.apache.org/ -type f -dist.apache.org//repos/dist/dev/yetus/0.2.0-RC1/CHANGELOG.md -dist.apache.org//repos/dist/dev/yetus/0.2.0-RC1/CHANGELOG.md.asc -dist.apache.org//repos/dist/dev/yetus/0.2.0-RC1/CHANGELOG.md.sha512 -dist.apache.org//repos/dist/dev/yetus/0.2.0-RC1/CHANGELOG.md.mds -dist.apache.org//repos/dist/dev/yetus/0.2.0-RC1/index.html -dist.apache.org//repos/dist/dev/yetus/0.2.0-RC1/RELEASENOTES.md -dist.apache.org//repos/dist/dev/yetus/0.2.0-RC1/RELEASENOTES.md.asc -dist.apache.org//repos/dist/dev/yetus/0.2.0-RC1/RELEASENOTES.md.sha512 -dist.apache.org//repos/dist/dev/yetus/0.2.0-RC1/RELEASENOTES.md.mds -dist.apache.org//repos/dist/dev/yetus/0.2.0-RC1/yetus-0.2.0-bin.tar.gz -dist.apache.org//repos/dist/dev/yetus/0.2.0-RC1/yetus-0.2.0-bin.tar.gz.asc -dist.apache.org//repos/dist/dev/yetus/0.2.0-RC1/yetus-0.2.0-bin.tar.gz.sha512 -dist.apache.org//repos/dist/dev/yetus/0.2.0-RC1/yetus-0.2.0-bin.tar.gz.mds -dist.apache.org//repos/dist/dev/yetus/0.2.0-RC1/yetus-0.2.0-src.tar.gz -dist.apache.org//repos/dist/dev/yetus/0.2.0-RC1/yetus-0.2.0-src.tar.gz.asc -dist.apache.org//repos/dist/dev/yetus/0.2.0-RC1/yetus-0.2.0-src.tar.gz.sha512 -dist.apache.org//repos/dist/dev/yetus/0.2.0-RC1/yetus-0.2.0-src.tar.gz.mds + +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. This is the KEYS file that should have been mentioned in the [VOTE] thread. The specific output of the follow commands will vary depending on how many release mangers there have been and which keys, if any, you have previously imported.</p> +<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 plaintext"><code>$ curl --output KEYS.yetus --silent 'https://www.apache.org/dist/yetus/KEYS' $ gpg --import KEYS.yetus gpg: key 0D80DB7C: "Sean Busbey (CODE SIGNING KEY) <[email protected]>" not changed @@ -375,51 +398,51 @@ 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="http://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="http://www.apache.org/info/verification.html";>What We Sign</a>. The following is a non-normative set of guidelines.</p> +<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 match. For example, using gpg and taking a fictional source artifact:</p> -<div class="highlight"><pre class="highlight plaintext"><code>$ cd dist.apache.org/repos/dist/dev/yetus/0.2.0-RC1/ -$ gpg --verify yetus-0.2.0-src.tar.gz.asc yetus-0.2.0-src.tar.gz +<li><p>You MUST make sure each of the signatures matches. For example, using gpg and taking a fictional source artifact:</p> +<div class="highlight"><pre class="highlight plaintext"><code>$ cd dist.apache.org/repos/dist/dev/yetus/0.7.0-RC1/ +$ gpg --verify 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 "Sean Busbey (CODE SIGNING KEY) <[email protected]>" </code></pre></div> -<p>As noted in the informational page <a href="http://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.</p></li> +<p>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.</p></li> <li><p>You MUST make sure the provided hashes match the provided artifact.</p> -<div class="highlight"><pre class="highlight plaintext"><code>$ gpg --print-mds yetus-0.2.0-src.tar.gz >yetus-0.2.0-src.tar.gz.my_mds -$ diff yetus-0.2.0-src.tar.gz.mds yetus-0.2.0-src.tar.gz.my_mds -$ shasum -a 512 yetus-0.2.0-src.tar.gz >yetus-0.2.0-src.tar.gz.my_sha512 -$ diff yetus-0.2.0-src.tar.gz.sha512 yetus-0.2.0-src.tar.gz.my_sha512 +<div class="highlight"><pre class="highlight plaintext"><code>$ gpg --print-mds apache-yetus-0.7.0-src.tar.gz >yetus-0.7.0-src.tar.gz.my_mds +$ diff apache-yetus-0.7.0-src.tar.gz.mds apache-yetus-0.7.0-src.tar.gz.my_mds +$ shasum -a 512 apache-yetus-0.7.0-src.tar.gz >yetus-0.7.0-src.tar.gz.my_sha512 +$ 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><p>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:</p> <ul> <li>our software must be under the Apache Software License version 2.0 and this must be noted with a proper LICENSE and NOTICE 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="http://apache.org/legal/src-headers.html";>Source Header Licensing Guide</a></li> -<li>our LICENSE and NOTICE files must properly propogate licensing information for bundled products. The <a href="http://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 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 LICENSE and NOTICE 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 run time 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> +<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. (This ASF policy is currently in DRAFT status.) Our eventual release tag is how we’ll provide long term provinence information for our downstream users. Since the release’s source code artifact will be the canonical represenation of the release we vote on, it’s important that it match the contents of the version control system’s tag. Given our example above, you can check this with recursive diff.</p> -<div class="highlight"><pre class="highlight plaintext"><code>$ mkdir yetus-0.2.0-src_unpack -$ tar -C yetus-0.2.0-src_unpack -xzf yetus-0.2.0-src.tar.gz -$ git clone --single-branch --depth=1 --branch 0.2.0-RC1 'https://git1-us-west.apache.org/repos/asf/yetus.git' yetus-0.2.0-RC1-tag -$ diff -r yetus-0.2.0-RC1-tag yetus-0.2.0-src_unpack/yetus-0.2.0 +<li><p>You SHOULD make sure the source release artifact corresponds to the referenced commit hash in the [VOTE] thread. (This ASF policy is currently in DRAFT status.) The release tag 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> +<div class="highlight"><pre class="highlight plaintext"><code>$ mkdir apache-yetus-0.7.0-src_unpack +$ tar -C apache-yetus-0.7.0-src_unpack -xzf apache-yetus-0.7.0-src.tar.gz +$ git clone --single-branch --depth=1 --branch 0.7.0-RC1 'https://git1-us-west.apache.org/repos/asf/yetus.git' apache-yetus-0.7.0-RC1-tag +$ diff -r apache-yetus-0.7.0-RC1-tag apache-yetus-0.7.0-src_unpack/yetus-0.7.0 $ echo $? 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 build helper script used to create the release artifacts.</p> -<div class="highlight"><pre class="highlight plaintext"><code>$ mkdir yetus-0.2.0-src_unpack -$ tar -C yetus-0.2.0-src_unpack -xzf yetus-0.2.0-src.tar.gz -$ cd yetus-0.2.0-src_unpack/yetus-0.2.0 -$ ./build.sh +<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 plaintext"><code>$ mkdir apache-yetus-0.7.0-src_unpack +$ tar -C apache-yetus-0.7.0-src_unpack -xzf apache-yetus-0.7.0-src.tar.gz +$ cd apache-yetus-0.7.0-src_unpack/yetus-0.7.0 +$ mvn clean install </code></pre></div> -<p>This will create a target/ directory that contains the tarball binary distribution. That tarball will also include e.g. the java jars we’ll push to maven for our Audience Annotations project.</p></li> +<p>This will create a yetus-dist/target/ directory that contains the tarball binary distribution files.</p></li> </ol> <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 releaddocmaker components and confirmed that the compilable components successfully compile.</p> +<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> @@ -503,13 +526,13 @@ $ /some/path/to/the/unpacked/candidate/bin/test-patch --project=hbase HBASE-1772 | unit | /testptch/patchprocess/patch-unit-hbase-server-jdk1.7.0_95.txt | | unit test 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: . | -| Powered by | Apache Yetus 0.2.0 http://yetus.apache.org | +| 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 verison.</p> -<div class="highlight"><pre class="highlight plaintext"><code>$ mkdir yetus-0.2.0-src_unpack -$ tar -C yetus-0.2.0-src_unpack -xzf yetus-0.2.0-src.tar.gz -$ cd yetus-0.2.0-src_unpack/yetus-0.2.0 -$ mvn --batch-mode -f yetus-project/pom.xml install +<div class="highlight"><pre class="highlight plaintext"><code>$ mkdir apache-yetus-0.7.0-src_unpack +$ tar -C apache-yetus-0.7.0-src_unpack -xzf apache-yetus-0.7.0-src.tar.gz +$ cd apache-yetus-0.7.0-src_unpack/yetus-0.7.0 +$ mvn --batch-mode install ...SNIP... [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS @@ -518,21 +541,8 @@ $ mvn --batch-mode -f yetus-project/pom.xml install [INFO] Finished at: 2016-02-13T02:12:39-06:00 [INFO] Final Memory: 14M/160M [INFO] ------------------------------------------------------------------------ -$ mvn --batch-mode -f audience-annotations-component/pom.xml install -...SNIP... -[INFO] Reactor Summary: -[INFO] -[INFO] Apache Yetus - Audience Annotations ................ SUCCESS [ 5.231 s] -[INFO] Apache Yetus - Audience Annotations Component ...... SUCCESS [ 0.037 s] -[INFO] ------------------------------------------------------------------------ -[INFO] BUILD SUCCESS -[INFO] ------------------------------------------------------------------------ -[INFO] Total time: 5.534 s -[INFO] Finished at: 2016-02-13T02:13:32-06:00 -[INFO] Final Memory: 24M/230M -[INFO] ------------------------------------------------------------------------ $ cd path/to/your/project -$ vim pom.xml # edit version to be e.g. 0.2.0 +$ vim pom.xml # edit version to be e.g. 0.7.0 $ mvn verify ...SNIP... [INFO] ------------------------------------------------------------------------ @@ -550,158 +560,121 @@ $ mvn verify <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> <ol> -<li><p>Create short cut links to the vote thread (e.g., <a href="http://s.apache.org/yetus-0.2.0-rc1-vote";>http://s.apache.org/yetus-0.2.0-rc1-vote</a>) and the result (e.g., <a href="http://s.apache.org/yetus-0.2.0-vote-passes";>http://s.apache.org/yetus-0.2.0-vote-passes</a>) that point to the archives on mail-archives.apache.org. Be aware that it may take several hours for the archive to get the posts that need to be referenced.</p></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 an 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.2.0 release and the RC1 example above has passed:</p> +<li><p>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 mail-archives.apache.org. Be aware that it may take several hours for the archive to get the posts that need to be referenced.</p></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.2.0 1e8f4588906a51317207092bd97b35687f2e3fa3 +$ git tag --sign rel/0.7.0 1e8f4588906a51317207092bd97b35687f2e3fa3 </code></pre></div> <p>Example commit message:</p> -<div class="highlight"><pre class="highlight plaintext"><code>YETUS-XXX. tag Apache Yetus 0.2.0 release. +<div class="highlight"><pre class="highlight plaintext"><code>YETUS-XXX. tag Apache Yetus 0.7.0 release. -vote thread: http://s.apache.org/yetus-0.2.0-rc1-vote +vote thread: https://s.apache.org/yetus-0.7.0-rc1-vote -results: http://s.apache.org/yetus-0.2.0-vote-passes +results: https://s.apache.org/yetus-0.7.0-vote-passes </code></pre></div> <p>Then push:</p> -<div class="highlight"><pre class="highlight plaintext"><code>$ git push origin rel/0.2.0 +<div class="highlight"><pre class="highlight plaintext"><code>$ 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> +<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.2.0 -$ cp path/to/yetus-dist-dev/0.2.0-RC1/* 0.2.0 -$ svn add 0.2.0 -$ svn commit -m "Publish Apache Yetus 0.2.0" +$ 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> <p>It may take up to 24 hours for the artifacts to make their way to the various mirrors. You should not announce the release until after this period.</p></li> -<li><p>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.</p></li> +<li><p>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.</p></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.2.0-RC* -D 0.2.0-RC1/yetus-0.2.0-src.tar.gz.sha512 -D 0.2.0-RC1/yetus-0.2.0-bin.tar.gz.asc -D 0.2.0-RC1/RELEASENOTES.md -D 0.2.0-RC1/CHANGELOG.md.mds -D 0.2.0-RC1/CHANGELOG.md.sha512 -D 0.2.0-RC1/yetus-0.2.0-src.tar.gz -D 0.2.0-RC1/RELEASENOTES.md.asc -D 0.2.0-RC1/yetus-0.2.0-bin.tar.gz.mds -D 0.2.0-RC1/yetus-0.2.0-bin.tar.gz.sha512 -D 0.2.0-RC1/yetus-0.2.0-src.tar.gz.asc -D 0.2.0-RC1/CHANGELOG.md -D 0.2.0-RC1/RELEASENOTES.md.mds -D 0.2.0-RC1/CHANGELOG.md.asc -D 0.2.0-RC1/RELEASENOTES.md.sha512 -D 0.2.0-RC1/yetus-0.2.0-bin.tar.gz -D 0.2.0-RC1/yetus-0.2.0-src.tar.gz.mds -D 0.2.0-RC1 -$ svn commit -m "cleaning up release candidates from Apache 0.2.0 release process." -Deleting 0.2.0-RC1 +$ 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 0.7.0 release process." +Deleting 0.7.0-RC1 Committed revision 1772. </code></pre></div></li> <li><p>Resolve release issue; it should be marked as <q>fixed.</q></p></li> -<li><p>Go to the <a href="http://repository.apache.org/";>ASF repository</a> and click ‘Release’ to put the RC Maven artifacts into the release repository.</p></li> -<li><p>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.</p></li> +<li><p>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.</p></li> +<li><p>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.</p></li> <li><p>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.</p> <div class="highlight"><pre class="highlight plaintext"><code>$ git push origin :YETUS-XXX </code></pre></div></li> <li><p>Update the Mac OS X Homebrew Formula:</p> <div class="highlight"><pre class="highlight plaintext"><code>$ vim Formula/yetus.rb -$ # change URL point to new version +$ # change URL point to the new version $ # update the sha256. e.g., shasum -a 256 bin.gz </code></pre></div></li> -<li><p>Update the documentation in the git master branch for the new release. Due to some limitations in our website rendering library, this currently involves some extra symlinks (see YETUS-192).</p> +<li><p>Update the documentation in the git master branch for the new release. Due to some limitations in our website rendering library, this currently involves some extra symlinks (see YETUS-192).</p></li> +<li><p>You should update the documentation in the git master branch. Remove the oldest release and add the latest.</p> <div class="highlight"><pre class="highlight plaintext"><code>$ cd asf-site-src $ # Add the release to the releases data file $ vim data/versions.yml -$ # create symlinks for where the documentation generation will go -$ cd source/documentation -$ ln -s ../../../target/0.2.0/ 0.2.0 -$ ln -s ../../../target/0.2.0.html.md 0.2.0.html.md -$ # add these symlinks to our rat exclusion file -$ cd ../../.. -$ vim .rat-excludes -$ # add changes to git +$ vim pom.xml +$ # add the two stanzas $ git add -p -$ git add asf-site-src/source/documentation/0.2.0* +$ git add asf-site-src/pom.xml $ git commit </code></pre></div> <p>Example commit message:</p> -<div class="highlight"><pre class="highlight plaintext"><code>YETUS-XXX. add release 0.2.0. +<div class="highlight"><pre class="highlight plaintext"><code>YETUS-XXX. add release 0.7.0. - list in releases - - add symlinks for markdown 3 workaround of per-version generated docs -</code></pre></div> -<p>This should result in a fairly small diff</p> -<div class="highlight"><pre class="highlight diff"><code>$ git diff HEAD^ -<span class="gh">diff --git a/.rat-excludes b/.rat-excludes -index 9332463..7b5f415 100644 -</span><span class="gd">--- a/.rat-excludes -</span><span class="gi">+++ b/.rat-excludes -</span><span class="gu">@@ -10,3 +10,5 @@ precommit-apidocs -</span> VERSION - 0.1.0 - 0.1.0.html.md -<span class="gi">+0.2.0 -+0.2.0.html.md -</span><span class="gh">diff --git a/asf-site-src/data/versions.yml b/asf-site-src/data/versions.yml -index ac9861c..4a4d4b5 100644 -</span><span class="gd">--- a/asf-site-src/data/versions.yml -</span><span class="gi">+++ b/asf-site-src/data/versions.yml -</span><span class="gu">@@ -16,3 +16,4 @@ -</span> # under the License. - releases: - - '0.1.0' -<span class="gi">+ - '0.2.0' -</span><span class="gh">diff --git a/asf-site-src/source/documentation/0.2.0 b/asf-site-src/source/documentation/0.2.0 -</span>new file mode 120000 -<span class="gh">index 0000000..158dc23 -</span><span class="gd">--- /dev/null -</span><span class="gi">+++ b/asf-site-src/source/documentation/0.2.0 -</span><span class="gu">@@ -0,0 +1 @@ -</span><span class="gi">+../../../target/0.2.0/ -</span>\ No newline at end of file -<span class="gh">diff --git a/asf-site-src/source/documentation/0.2.0.html.md b/asf-site-src/source/documentation/0.2.0.html.md -</span>new file mode 120000 -<span class="gh">index 0000000..c14ca73 -</span><span class="gd">--- /dev/null -</span><span class="gi">+++ b/asf-site-src/source/documentation/0.2.0.html.md -</span><span class="gu">@@ -0,0 +1 @@ -</span><span class="gi">+../../../target/0.2.0.html.md -</span>\ No newline at end of file -</code></pre></div> -<p>You should then post this patch for review. Once you’ve gotten feedback, it’s fine to push the patch to the ASF git repo immediately so long as the updated website is not published.</p></li> -<li><p>Publish website updates. After the 24 hour window needed for the release artifacts to make their way to the variety of mirrors, you should render the website and publish it using the instructions found in <a href="../website">Maintaining the Yetus Website</a>.</p></li> -<li><p>Remove old releases from 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 maintanence for an earlier minor or major release line, you should delete those versions from the distribution area.</p></li> -<li><p>Publish convenience artifacts (maven, homebrew, etc). Specifics to be documented later; see <a href="https://issues.apache.org/jira/browse/YETUS-316";>YETUS-316</a>.</p></li> + - remove 0.4.0, add 0.7.0 to pom.xml +</code></pre></div></li> +</ol> + +<p>You should then post this patch for review. Once you’ve gotten feedback, it’s fine to push the patch to the ASF git repo immediately so long as the updated website is not published.</p> + +<ol> +<li>Publish website updates. After the 24 hour window needed for the release artifacts to make their way to the variety of mirrors, you should render the website and publish it using the instructions found in <a href="../website">Maintaining the Yetus Website</a>.</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>Publish convenience artifacts (maven, homebrew, etc.). Specifics to be documented later; see <a href="https://issues.apache.org/jira/browse/YETUS-316";>YETUS-316</a>.</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, - Subject: [ANNOUNCE] Apache Yetus 0.2.0 release</p> -<div class="highlight"><pre class="highlight plaintext"><code>Apache Yetus 0.2.0 Released! + 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.2.0 of Apache Yetus. +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 tooling to help release managers +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: +To download, please choose a mirror by visiting: https://yetus.apache.org/downloads/ The relevant checksums files are available at: - https://www.apache.org/dist/yetus/0.2.0/yetus-0.2.0-src.tar.gz.mds - https://www.apache.org/dist/yetus/0.2.0/yetus-0.2.0-bin.tar.gz.mds + https://www.apache.org/dist/yetus/0.7.0/apache-yetus-0.7.0-src.tar.gz.sha512 + https://www.apache.org/dist/yetus/0.7.0/apache-yetus-0.7.0-src.tar.gz.mds + https://www.apache.org/dist/yetus/0.7.0/apache-yetus-0.7.0-bin.tar.gz.sha512 + https://www.apache.org/dist/yetus/0.7.0/apache-yetus-0.7.0-bin.tar.gz.mds Project member signature keys can be found at @@ -709,17 +682,17 @@ Project member signature keys can be found at PGP signatures are available at: - https://www.apache.org/dist/yetus/0.2.0/yetus-0.2.0-src.tar.gz.asc - https://www.apache.org/dist/yetus/0.2.0/yetus-0.2.0-bin.tar.gz.asc + https://www.apache.org/dist/yetus/0.7.0/apache-yetus-0.7.0-src.tar.gz.asc + https://www.apache.org/dist/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.2.0/CHANGELOG/ - https://yetus.apache.org/documentation/0.2.0/RELEASENOTES/ + 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.2.0/ + https://yetus.apache.org/documentation/0.7.0/ On behalf of the Apache Yetus team, thanks to everyone who helped with this release! @@ -733,13 +706,13 @@ Meg Smith Apache Yetus PMC </code></pre></div> <p>If you’d like feedback on the draft, feel free to post it for review on your release issue.</p></li> -<li><p>Send announcement emails. After the 24 hour window needed for the release artifacts to make their way to the variety of mirrors, you should send the announcement email. The email should come from your apache.org email address and at a minimum should go to the <a href="mailto:[email protected]";>[email protected]</a> and <a href="mailto:[email protected]";>[email protected]</a> lists. For details see <a href="http://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.</p></li> -<li><p>Send tweet. Once the message to the ASF-wide announce list has made it to the public archive, you should draft a tweet with a link to the announcement. You should use the ASF link shortener and a descriptive name. For example, the 0.2.0 release could use</p> -<div class="highlight"><pre class="highlight plaintext"><code>Apache Yetus 0.2.0 has been released: +<li><p>Send announcement emails. After the 24 hour window needed for the release artifacts to make their way to the variety of mirrors, you should send the announcement email. The email should come from your apache.org email address and at a minimum should go to the <a href="mailto:[email protected]";>[email protected]</a> and <a href="mailto:[email protected]";>[email protected]</a> lists. 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.</p></li> +<li><p>Send tweet. Once the message to the ASF-wide announce list has made it to the public archive, you should draft a tweet with a link to the announcement. You should use the ASF link shortener and a descriptive name. For example, the 0.7.0 release could use</p> +<div class="highlight"><pre class="highlight plaintext"><code>Apache Yetus 0.7.0 has been released: -http://s.apache.org/yetus-0.2.0-announce +https://s.apache.org/yetus-0.7.0-announce </code></pre></div> -<p>This tweet should come from the offical <a href="https://twitter.com/ApacheYetus/";>@ApacheYetus</a> account. Currently only PMC members have access to it. If you are not yet on the PMC, please ask for the PMC to post the tweet once your email is available in the archives.</p></li> +<p>This tweet should come from the official <a href="https://twitter.com/ApacheYetus/";>@ApacheYetus</a> account. Currently, only PMC members have access to it. If you are not yet on the PMC, please ask for the PMC to post the tweet once your email is available in the archives.</p></li> </ol> </div>
