This is an automated email from the ASF dual-hosted git repository.
awong pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/kudu.git
commit 8f946f4d8d33755a65121d4c49b05db36bdb14f9
Author: Andrew Wong <awong@apache.org>
AuthorDate: Tue Mar 12 18:39:27 2019 -0700
docs: small updates to RELEASING docs
Unfamiliar with Maven Central, Subversion, and the end-to-end release
process, even with the releasing docs, I was unsure of a few things.
I've added some minor bits of info that might be helpful for future
release managers.
Change-Id: I3e6d6f7024cb32f8e0cd726e9d2652fddc688fe9
Reviewed-on: http://gerrit.cloudera.org:8080/12742
Tested-by: Andrew Wong <awong@cloudera.com>
Reviewed-by: Mike Percy <mpercy@apache.org>
---
RELEASING.adoc | 68 ++++++++++++++++++++++++++++++++--------------------------
1 file changed, 37 insertions(+), 31 deletions(-)
diff --git a/RELEASING.adoc b/RELEASING.adoc
index 4d6839e..4c5617c 100644
--- a/RELEASING.adoc
+++ b/RELEASING.adoc
@@ -50,8 +50,8 @@ in `master`.
----
. Push the branch to public remotes https://github.com/cloudera/kudu.git and
-https://gitbox.apache.org/repos/asf/kudu.git. The following example
-assumes they are called `cloudera` and `apache`.
+ https://gitbox.apache.org/repos/asf/kudu.git. The following example assumes
+ they are called `cloudera` and `apache`.
+
----
git push cloudera branch-1.x.y
@@ -59,8 +59,8 @@ assumes they are called `cloudera` and `apache`.
----
. Create a new branch on Gerrit. Go to
-http://gerrit.cloudera.org:8080/#/admin/projects/kudu,branches and create a new
-branch with the same name and the previously-noted SHA1.
+ http://gerrit.cloudera.org:8080/#/admin/projects/kudu,branches and create a
+ new branch with the same name and the previously-noted SHA1.
. Ask someone with permissions to fix the gerrit.cloudera.org mirroring
configuration. Cloudera hosts the Gerrit server and a Cloudera employee will
@@ -128,8 +128,9 @@ Apache committer guide for setting up your GPG keys
. Build a source tarball against the RC branch.
-. Create a new folder in https://dist.apache.org/repos/dist/dev/kudu/.
- Copy the artifacts to this folder and commit (it is Subversion).
+. Create a new folder containing the
+ link:https://dist.apache.org/repos/dist/dev/kudu/[dev Subversion (SVN)
+ repository]. Copy the artifacts to this folder and commit.
+
----
svn co --depth=immediates https://dist.apache.org/repos/dist/dev/kudu/ kudu-dev-release
@@ -149,16 +150,19 @@ Apache committer guide for setting up your GPG keys
gradle clean uploadArchives -PmavenUsername="<APACHE-LDAP-USERNAME>" -PmavenPassword="<APACHE-LDAP-PASSWORD>"
----
+
-Go to the link:https://repository.apache.org/\#stagingRepositories[staging repository]
-and look for ‘orgapachekudu-####’ in the staging repositories list. You can
-check the ‘content’ tab at the bottom to make sure you have all of the expected
-stuff (client, various integrations, etc). Hit the checkbox next to your new
-staging repo and hit “close”. Enter something similar to “Apache Kudu 1.x.y-RC1”
-into the description box and confirm. Wait a minute or two and hit refresh, and
-your staging repo should now have a URL shown in its summary tab (eg
-`https://repository.apache.org/content/repositories/orgapachekudu-1005`)
-
-. Add your PGP key to the KEYS file:
+Go to the link:https://repository.apache.org/\#stagingRepositories[staging
+repository] and look for ‘orgapachekudu-####’ in the staging repositories list.
+You can check the ‘content’ tab at the bottom to make sure you have all of the
+expected stuff (client, various integrations, etc). Hit the checkbox next to
+your new staging repo and hit “close”. Enter something similar to “Apache Kudu
+1.x.y-RC1” into the description box and confirm. Wait a minute or two and hit
+refresh, and your staging repo should now have a URL shown in its summary tab
+(eg `https://repository.apache.org/content/repositories/orgapachekudu-1005`)
+
+. Create a new folder containing the
+ link:https://dist.apache.org/repos/dist/release/kudu/[release SVN
+ repository]. For a release to be made official, it must eventually be put in
+ this repository. Add your PGP key to the KEYS file:
+
----
svn co https://dist.apache.org/repos/dist/release/kudu/ kudu-dist-release
@@ -181,24 +185,24 @@ svn commit -m "Adding my key to the KEYS file"
. Always send an email with a different subject to indicate the result. For
link:http://mail-archives.apache.org/mod_mbox/kudu-dev/201606.mbox/%3CCAGpTDNeJdU%2BoUF4ZJneZt%3DCfFHY-HoqKgORwVuWWUMHq5jBNzA%40mail.gmail.com%3E[example].
-. After the vote passes, send an email to dev@kudu.apache.org
- indicating the result.
+. After the vote passes, send an email to dev@kudu.apache.org indicating the
+ result.
== Release
-. Create a new folder in https://dist.apache.org/repos/dist/release/kudu/,
- copy the files from the release candidate’s folder in dist/dev/kudu/, then commit.
+. Create a new folder in the release repository for the new release and copy
+ the files from the dev repository.
+
----
cd kudu-dist-release
mkdir 1.x.y
- cp <path_to_rc_artifacts>/* 1.x.y
+ cp <path_to_kudu-dev-release>/1.x.y-RC1/* 1.x.y
svn add 1.x.y
svn commit -m "Adding files for Kudu 1.x.y"
----
. In the Kudu git repo, create a signed tag from the RC’s tag, and push it to the
-Apache Git repository:
+ Apache Git repository:
+
----
git tag -s 1.x.y -m 'Release Apache Kudu 1.x.y' 1.x.y-RC1
@@ -207,7 +211,8 @@ Apache Git repository:
. Release the staged Java artifacts. Select the release candidate staging
repository in link:https://repository.apache.org/#stagingRepositories[Nexus],
- and click 'Release'.
+ and click 'Release'. You should shortly be able to see the artifacts in
+ link:https://search.maven.org/search?q=g:org.apache.kudu[Maven Central].
. Release the Python artifacts. You will need to setup an account on link:https://PyPi.org[PyPi.org]
and ask to be added to the kudu-python PyPi project if you have not done this before.
@@ -235,21 +240,22 @@ Note: You can upload to the test PyPi by adding
copy the `apidocs`, `cpp-client-api`, and `docs` folders there, copy an `index.md` file
from one
of the other releases and modify it accordingly.
-. Commit all these changes.
-
-. Create a new review for all those new and updated files in `gh-pages`.
+. Submit these changes to the `gh-pages` Gerrit branch and get them reviewed.
. Once the review is finished and the commit is pushed, update the website following
these link:https://github.com/apache/kudu/#deploying-changes-to-the-apache-kudu-web-site[instructions].
. About 24 hours after the first step was completed, send an email to
- user@kudu.apache.org, dev@kudu.apache.org, and announce@apache.org
- to announce the release. The email should be similar to
+ user@kudu.apache.org, dev@kudu.apache.org, and announce@apache.org to
+ announce the release. The email should be similar to
link:https://s.apache.org/pduz[this].
-. About another 24 hours later, delete the previous minor version in the branch
- you released from, from SVN. For example, if you released 1.2.1, delete `1.2.0`.
- Also delete any release candidates from the dev SVN.
+. About another 24 hours later, clean up the SVN. If releasing a new minor
+ version, delete the oldest minor version branch in the release repo (e.g. if
+ `1.7.1`, `1.8.0`, and `1.9.0` exist and you just released `1.10.0`, delete
+ `1.7.1`). If releasing a maintenance version, delete the previous maintenance
+ branch (e.g. if you released `1.2.1`, delete `1.2.0`). Also delete any
+ release candidates from the dev SVN.
. Update the version number on the branch you released from back to a SNAPSHOT
for the next patch release, such as `1.6.1-SNAPSHOT` after the `1.6.0` release.
|