This is an automated email from the ASF dual-hosted git repository.
jiwq pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/submarine.git
The following commit(s) were added to refs/heads/master by this push:
new 534d7ee SUBMARINE-538. Update the preparation content in release doc
534d7ee is described below
commit 534d7ee2f32e7795b7b856c64919b549b7aec4c4
Author: Wanqiang Ji <[email protected]>
AuthorDate: Mon Aug 10 23:57:18 2020 +0800
SUBMARINE-538. Update the preparation content in release doc
### What is this PR for?
update the release steps
### What type of PR is it?
[Improvement]
### Todos
### What is the Jira issue?
https://issues.apache.org/jira/browse/SUBMARINE-538
### How should this be tested?
### Screenshots (if appropriate)
### Questions:
* Does the licenses files need update? No
* Is there breaking changes for older versions? No
* Does this needs documentation? No
Author: Wanqiang Ji <[email protected]>
Closes #320 from jiwq/SUBMARINE-538 and squashes the following commits:
0dc6b17 [Wanqiang Ji] SUBMARINE-538. Update the release doc
---
dev-support/cicd/HowToRelease.md | 88 +++++++++++++++++++++-------------------
1 file changed, 47 insertions(+), 41 deletions(-)
diff --git a/dev-support/cicd/HowToRelease.md b/dev-support/cicd/HowToRelease.md
index 2149550..7112d82 100644
--- a/dev-support/cicd/HowToRelease.md
+++ b/dev-support/cicd/HowToRelease.md
@@ -1,80 +1,81 @@
# How To Release Apache Submarine
-This document is for Apache Submarine committer and PMCs to do a new release.
+This document is for Apache Submarine Release Manager to do a new release.
-## Preparation
+## 1. Preparation
If you have not already done so, generate your PGP key and append your
[signing key](http://www.apache.org/dev/release-signing.html#keys-policy) to
the [KEYS](https://dist.apache.org/repos/dist/release/submarine/KEYS) file.
Once you commit your changes (ask for PMC's help if you cannot), they will
automatically be propagated to the website. Also upload your key to a public
key server if you haven't.
-End users use the KEYS file to validate that releases were done by an Apache
committer.
+End users use the KEYS file to validate that releases were done by an Apache
Committer.
```
-# generate key and upload to the public
+# generate key and send keys to a keyserver
gpg --gen-key
gpg --list-sigs <your name>
-gpg --keyserver pgp.mit.edu --send-key <your publish key RSA string like
B3097AC in the above cmd output>
+gpg --keyserver pgp.mit.edu --send-keys <your publish key RSA string like
B3097AC in the above cmd output>
gpg --refresh-keys --keyserver pgp.mit.edu
-# adding your key to submarine KEYS
-gpg --list-sigs <your name> >> ~/key.txt
-gpg --armor --export <your name> >> ~/key.txt
+
+# adding your key to the submarine KEYS (Only PMCs has permission)
svn co --depth immediates https://dist.apache.org/repos/dist apache-dist
cd apache-dist
svn update --set-depth infinity release/submarine
cd release/submarine
-echo ~/key.txt >> KEYS
-svn add KEYS
+gpg --list-sigs <your name> >> KEYS
+gpg --armor --export <your name> >> KEYS
svn ci -m "Add <your name>'s key"
```
-## Release Plan
+## 2. Send Release Plan
It's better to send a release plan email informing code freeze date and
release date.
-## Clean up the JIRA
+## 3. Clean up the JIRA
Bulk update JIRA to unassign from this release all issues that are open
non-blockers.
-Assuming we're releasing version X, use below advanced filter in [submarine
issue page](https://issues.apache.org/jira/projects/SUBMARINE). For instance,
if we're releasing 0.3.0.
+Assuming we're releasing version X, use below advanced filter in [submarine
issue page](https://issues.apache.org/jira/projects/SUBMARINE). For instance,
if we're releasing `0.3.0`.
```
project in ("Apache Submarine") AND "Target Version" = 0.3.0 AND
statusCategory != Done
```
Click "tools"-> "bulk update" to edit all issues:
-1. Change the target version to X+1. Here it is 0.4.0
-2. Add a comment to inform contributors. Like this "Bulk update due to
releasing 0.3.0. Please change it back if you think this is a blocker."
+1. Change the target version to X+1. Here it is `0.4.0`.
+2. Add a comment to inform contributors. Like this `Bulk update due to
releasing 0.3.0. Please change it back if you think this is a blocker.`
-Do a double-check to confirm that there's no issues found with the above
filter. And send mail to the developer list informing that we should mark
"Target version" to 0.4.0 when creating new JIRAs.
+Do a double-check to confirm that there's no issues found with the above
filter. And send mail to the developer list informing that we should mark
"Target version" to `0.4.0` when creating new JIRAs.
-## Tagging
+## 4. Tagging
Once the JIRA is cleaned up, we can tag the candidate release with below steps:
```
export version=0.3.0
-export cversion=0.3.0-RC0
+export cversion=$version-RC0
export tag=release-$cversion
-git tag -s release-$version -m "Release candidate - $version"
+
+git tag -s $tag -m "Release candidate - $version"
# Verify the tag is signed with your GPG key
-git tag -v release-$cversion
-# Push the tag to upstream
-git push origin release-$cversion
+git tag -v $tag
+# Push the tag to apache repo
+git push origin $tag
```
-## Build Artifacts
-
+## 5. Build Artifacts
The submarine artifacts consists of GPG signed source code tarball, binary
tarball and docker images.
```
-cd submarine/dev-support/cicd/
+cd dev-support/cicd/
./create_release.sh $version $tag
-#Move the artifacts to a folder instead of /tmp/
+# Move the artifacts to a folder instead of /tmp/
mv /tmp/submarine-release ~/
```
+> Note: In here we use the `version` not the `cversion`.
-## Upload Artifacts For Vote
+## 6. Upload Artifacts For Vote
Before the uploading, we need to do some basic testing for the release
candidates. For instance, build from the source tarball and run feature test
using the binary tarball.
-### Staging Source and Binary Tarball to self FTP server
+### 6.1 Staging Source and Binary Tarball to self FTP server
```
cd ~/submarine-release
sftp home.apache.org
+# if not exits, please mkdir
cd public_html
-mkdir submarine-0.3.0-RC0
+mkdir submarine-$cversion && cd $_
put -r .
exit
```
-### Staging Docker Images
-#### Package An Existing Release Candidates
+
+### 6.2 Staging Docker Images
When doing release, the release manager might needs to package an artifact
candidates in this docker image and public the image candidate for a vote.
In this scenario, we can do this:
@@ -96,7 +97,10 @@ In the container, we can verify that the submarine jar
version is the expected 0
```
docker push apache/mini-submarine:0.3.0:RC0
```
-### Publish Jars To Apache Maven Staging Repository
+
+TODO: build the other images by manual.
+
+### 6.3 Publish Jars To Apache Maven Staging Repository
```
export GPG_PASSPHRASE=yourPassphase
export ASF_USERID=yourApacheId
@@ -106,21 +110,22 @@ export ASF_PASSWORD=yourApachePwd
Then to view the staging repo, we can login the the
https://repository.apache.org with the apache id. Click the "Staging
Repositories" in the left side of the web page. And click
"orgapachesubmarine-1001", then you will see the details of the repo including
the URI. The URI is like this:
"https://repository.apache.org/content/repositories/orgapachesubmarine-1001";
-### Call A Vote For The Release Candidate
+### 6.4 Call A Vote For The Release Candidate
After the artifacts and images are staged, we can send a vote email to the
community. It's recommended that we paste the URI of RC tag, RC release
artifacts, docker images, maven staging repository and the KEYS.
Refer to
[here](https://www.mail-archive.com/[email protected]/msg01498.html) for
an example.
-## Release
-In several days if the [vote
passes](http://hadoop.apache.org/bylaws#Decision+Making), we can publish the
release.
-If the vote fails, then we need to start another RC from tagging to the
staging.
+## 7. Release
+In several days if the [vote
passes](http://hadoop.apache.org/bylaws#Decision+Making), we can publish the
release. If the vote fails, then we need to start another RC from
[cleanup](#3.-Clean-up-the-JIRA) to the
[staging](#6.-Upload-Artifacts-For-Vote).
1. Access [submarine project version
page](https://issues.apache.org/jira/projects/SUBMARINE?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page&status=unreleased).
Click the version to be released, and then click the "Release" button. It will
request the release date. We can fill it with the end-of-vote date.
-2. Tag the release.
+2. Tag the release
```
+# please replace the version to the right version
export version=0.3.0
-git tag -s rel/release-${version} -m "Submarine ${version} release"
-git push origin rel/release-${version}
+export tag=rel/release-$version
+git tag -s $tag -m "Submarine ${version} release"
+git push origin $tag
```
3. Copy release artifacts to apache dist server
@@ -143,7 +148,7 @@ Usually binary tarball becomes larger than 300MB, so it
cannot be directly uploa
4. In [Nexus](https://repository.apache.org/), effect the release of artifacts
by selecting the staged repository and then clicking Release. If there were
multiple RCs, simply drop the staging repositories corresponding to failed RCs.
-5. Upload the images
+5. Upload the docker images
```
docker tag apache/submarine:mini-0.3.0-RC0 apache/submarine:mini-0.3.0
docker push apache/submarine:mini-0.3.0
@@ -151,7 +156,7 @@ docker push apache/submarine:mini-0.3.0
6. Update the version in pom.xml
```
-# if the new version a a point release
+# if the new version a point release
mvn versions:set -DgenerateBackupPoms=false -DnewVersion=X.(Y+1).Z-SNAPSHOT
git commit -a -m "Preparing for X.(Y+1).Z development"
```
@@ -182,4 +187,5 @@ cd /submarine-site
bundle exec jekyll serve --watch --host=0.0.0.0
# Open another terminal, you can edit MD files and refresh the webpage to see
changes instantly.
```
+
9. Send announcements to the user and developer lists once the site changes
are visible.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
