This is an automated email from the ASF dual-hosted git repository.
style95 pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/openwhisk-release.git
The following commit(s) were added to refs/heads/master by this push:
new e28b538 Elaborate the release instruction (#357)
e28b538 is described below
commit e28b53818ba29d97aa9d8786ac13b259990adcf2
Author: Dominic Kim <[email protected]>
AuthorDate: Wed Nov 18 10:06:34 2020 +0900
Elaborate the release instruction (#357)
* Elaborate the release instruction
* Update docs/release_instructions.md
Co-authored-by: rodric rabbah <[email protected]>
* Update docs/release_instructions.md
Co-authored-by: rodric rabbah <[email protected]>
* Update docs/release_instructions.md
Co-authored-by: rodric rabbah <[email protected]>
Co-authored-by: rodric rabbah <[email protected]>
---
docs/release_instructions.md | 44 +++++++++++++++++++++++++++++++++++++++++++-
docs/tag_release.md | 2 +-
2 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/docs/release_instructions.md b/docs/release_instructions.md
index a20030e..63d54a3 100644
--- a/docs/release_instructions.md
+++ b/docs/release_instructions.md
@@ -91,6 +91,41 @@ Before creating release artifacts, the Release Manager
should initiate a communi
3. If a component being released includes a changelog or release notes file,
make sure they are up-to-date.
4. If you are releasing either the `openwhisk` or `openwhisk-deploy-kube`
repositories create a release branch in the Apache git repo. Then submit a PR
to that release branch to change all uses of the `nightly` tag to fixed tags
(eg `1.14.0` or `8eb922f`).
+### (Optional) Make a branch to create a Release
+
+This step is only required when making a release for the `openwhisk` or
`openwhisk-deploy-kube` repositories.
+
+1. Create a Release branch with the version name in the upstream repository.
+
+Please be noted that the branch should be created in the upstream repository,
not a forked repository.
+This branch would not be merged into the master branch and stay as a
standalone branch.
+
+```bash
+$ git checkout -b 1.0.0
+$ git push upstream 1.0.0
+```
+
+2. Add commits to this branch to make a Release.
+
+Sometimes, it is required to add a release specific commit. For example, the
Docker image tag for runtimes should be updated to other than `nightly`.
+The Release Manager is supposed to open relevant PRs directly against the
release branch and merge them.
+
+3. Open a PR with the release branch.
+
+You can make sure the branch passes all CI tests whenever the branch changes.
+
+
+4. Trigger the Jenkins job to build Docker images.
+
+Docker images built with the release version is required to run the standalone
OpenWhisk without any local build.
+
+The following job is intended to build a release branch and publish images to
the Docker hub.
+The Release Manager should update the branch specifier in the Jenkins job.
+
+https://ci-builds.apache.org/job/OpenWhisk/job/OpenWhisk-DockerHub-ReleaseBranch/
+
+This job is supposed to be disabled after the release process is over.
+
### Defining the Release Contents
The contents of a release are defined by a JSON configuration file.
@@ -132,13 +167,18 @@ provide historical documentation of project releases.
- repository: URL of the repository
- branch: git branch being released (`master` or a release branch name)
-**Important Note:** If you are releasing a Node.js package which
+**Important Note 1:** If you are releasing a Node.js package which
contains a `package.json`, you should make sure the `version`
specified in `package.json` matches your release version. If you
also have a `package-lock.json` file, it too must have a matching
`version` property. See additional tips for [releasing npm
packages](#publishing-to-npm).
+**Important Note 2:** If you are releasing the `openwhisk` or
`openwhisk-deploy-kube` repositories,
+the branch and commit hash in the release contents should be the release
branch and the latest commit hash in the release branch.
+Please be careful not to use the `master` branch.
+
+
### Create Release Candidates
From the [tools directory](../tools), execute the script
@@ -375,3 +415,5 @@ of the release manager.
2. If there is a prior release, remove it from the release svn
(all releases are automatically archived, removing an old release
from dist does not remove it from the archive).
+3. Disable the Jenkins job to build and push Docker images to Docker hub if
you released the `openwhisk` or `openwhisk-deploy-kube` repositories.
+4. Close the PR for the release branch if you released the `openwhisk` or
`openwhisk-deploy-kube` repositories.
diff --git a/docs/tag_release.md b/docs/tag_release.md
index 3334b7d..306eaf4 100644
--- a/docs/tag_release.md
+++ b/docs/tag_release.md
@@ -33,7 +33,7 @@ git push <remote_url_var> <tag>
Replace the notation \<tag\> with the tag name for the release of the current
project. As a release manager, you should be
familiar with the tag's naming convention for the module to be released. Take
the Nodejs runtime as example, you need to use
-the tag like \<node kind\>@\<version\>-\<pre_release_version\>. The nonation
\<node kind\> should be 8 or 10 for a specific
+the tag like \<node kind\>@\<version\>-\<pre_release_version\>. The notation
\<node kind\> should be 8 or 10 for a specific
Nodejs version, but for OpenWhisk, you can directly use
\<version\>-\<pre_release_version\> as the tag. Please make sure
you use the correct format of tags, when you release OpenWhisk modules. If you
are not sure how to name the tag, ask the
OpenWhisk community.
