You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@yetus.apache.org by aw...@apache.org on 2019/03/03 04:20:49 UTC
[yetus] branch master updated: YETUS-769. release documentation
updates from 0.9.0
This is an automated email from the ASF dual-hosted git repository.
aw pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/yetus.git
The following commit(s) were added to refs/heads/master by this push:
new 9c7ec4b YETUS-769. release documentation updates from 0.9.0
9c7ec4b is described below
commit 9c7ec4bb34fc58036456feb0fde8dd68d98ced78
Author: Allen Wittenauer <aw...@apache.org>
AuthorDate: Sat Feb 23 10:11:02 2019 -0800
YETUS-769. release documentation updates from 0.9.0
Signed-off-by: Allen Wittenauer <aw...@apache.org>
---
asf-site-src/source/contribute/releases.md | 22 +++++++++++++---------
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/asf-site-src/source/contribute/releases.md b/asf-site-src/source/contribute/releases.md
index f75bcd3..be51250 100644
--- a/asf-site-src/source/contribute/releases.md
+++ b/asf-site-src/source/contribute/releases.md
@@ -61,6 +61,10 @@ All of these tools should be in the Docker container that is launched by using t
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.
+### Verify the Year
+
+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!
+
### Ensure Your Public Key is in KEYS
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: https://www.apache.org/dist/yetus/KEYS. You can read about this file in the ASF guide to release signing's section [The KEYS File](https://www.apache.org/dist/yetus/KEYS). 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 t [...]
@@ -178,7 +182,7 @@ Now update these files, but this time you should update them for the next minor
```
-$ perl -pi -e 's,0.7.0-SNAPSHOT,0.8.0,g' $(find . -type f)
+$ perl -pi -e 's,0.7.0-SNAPSHOT,0.8.0-SNAPSHOT,g' $(find . -type f)
```
After you are done, create a patch.
@@ -195,11 +199,11 @@ Both of these patch files should be uploaded to your release issue for review. 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 [ASF Voting Policy](https://www.apache.org/foundation/voting.html)), 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 [...]
-1. Update JIRA version release date. Browse to the JIRA project version management page (https://issues.apache.org/jira/plugins/servlet/project-config/YETUS/versions) and set the release date to when you expect your next vote thread to close. Our generated release notes will use this date.
+1. Update JIRA version release date. Browse to the JIRA project version management page (https://issues.apache.org/jira/plugins/servlet/project-config/YETUS/versions), mark the version as 'Release', and set the release date. Our generated release notes will use this date.
1. Update your `${HOME}/.m2/settings.xml` file to include the Maven snapshot information as indicated on https://www.apache.org/dev/publishing-maven-artifacts.html
1. 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:
- $ mvn --batch-mode clean install -Papache-release
+ $ mvn --batch-mode clean deploy -Papache-release
$ mvn --batch-mode site site:stage
$ ls -lah yetus-dist/target/artifacts/*
1. Check out the staging area for release candidates and make a directory for this candidate, somewhere outside of your working directory. Copy the artifacts (**except for the site.tar.gz**) from the previous step into place. For example, when working on RC1 for the 0.7.0 release
@@ -479,6 +483,7 @@ Example commit message:
Then push:
$ git push origin rel/0.7.0
+1. 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 [Apache Committee Report Helper website](https://reporter.apache.org/addrelease.html?yetus). 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 inf [...]
1. 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 _exactly_ 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 t [...]
$ svn co https://dist.apache.org/repos/dist/release/yetus/ yetus-dist-release
@@ -488,7 +493,6 @@ Then push:
$ svn add 0.7.0
$ svn commit -m "Publish Apache Yetus 0.7.0"
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.
-1. 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 [Apache Committee Report Helper website](https://reporter.apache.org/addrelease.html?yetus). 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 inf [...]
1. 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.
$ svn co https://dist.apache.org/repos/dist/dev/yetus/ yetus-dist-dev
@@ -511,7 +515,7 @@ It may take up to 24 hours for the artifacts to make their way to the various mi
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."
+ $ svn commit -m "cleaning up release candidates from Apache Yetus 0.7.0 release process."
Deleting 0.7.0-RC1
Committed revision 1772.
@@ -526,8 +530,9 @@ It may take up to 24 hours for the artifacts to make their way to the various mi
$ vim Formula/yetus.rb
$ # change URL point to the new version
$ # update the sha256. e.g., shasum -a 256 bin.gz
-1. 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).
-1. You should update the documentation in the git master branch. Remove the oldest release and add the latest.
+ $ # test the formula:
+ $ brew install --build-from-source Formula/yetus.rb
+1. Update the documentation in the git master branch for the new release. Remove the oldest release and add the latest.
$ cd asf-site-src
$ # Add the release to the releases data file
@@ -545,10 +550,9 @@ Example commit message:
- remove 0.4.0, add 0.7.0 to pom.xml
-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.
+1. You should then post this patch for review. Once you've gotten feedback, it's fine to push the patch to the ASF source repo immediately so long as the updated website is not published.
1. 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 [Maintaining the Yetus Website](../website).
1. 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.
-1. Publish convenience artifacts (maven, homebrew, etc.). Specifics to be documented later; see [YETUS-316](https://issues.apache.org/jira/browse/YETUS-316).
1. 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.7.0 release