You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pulsar.apache.org by hj...@apache.org on 2019/12/05 04:36:23 UTC
[pulsar.wiki] branch master updated: Updated Release process
(markdown)
This is an automated email from the ASF dual-hosted git repository.
hjf pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/pulsar.wiki.git
The following commit(s) were added to refs/heads/master by this push:
new 0341350 Updated Release process (markdown)
0341350 is described below
commit 034135059708a1e0f1db868f975cc233f8140ded
Author: Jennifer Huang <47...@users.noreply.github.com>
AuthorDate: Thu Dec 5 12:36:19 2019 +0800
Updated Release process (markdown)
---
Release-process.md | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/Release-process.md b/Release-process.md
index 44ab0c7..eef9ab4 100644
--- a/Release-process.md
+++ b/Release-process.md
@@ -2,11 +2,11 @@
This page contains instructions for Pulsar committers on
how to perform a release.
-If you haven't already did it. Create and publish the GPG
+If you haven't already done it, create and publish the GPG
key with which you'll be signing the release artifacts.
Instructions are at [Create GPG keys to sign release artifacts](https://github.com/apache/pulsar/wiki/Create-GPG-keys-to-sign-release-artifacts).
-## Making the release
+## Release workflow
The steps for releasing are as follows:
1. Create release branch
@@ -36,12 +36,10 @@ applied as part of the maintenance for the release.
The branch needs only to be created when creating major releases,
and not for patch releases.
-Eg: When creating `v2.3.0` release, will be creating
-the branch `branch-2.3`, but for for `v2.3.1` we
-would keep using the old `branch-2.3`.
+Eg: When creating `v2.3.0` release, the branch `branch-2.3` will be created; but for `v2.3.1`, we
+keep using the old `branch-2.3`.
-In these instructions, I'm referring to an fictitious release `2.X.0`. Change the release version in the examples
-accordingly with the real version.
+In these instructions, I'm referring to an fictitious release `2.X.0`. Change the release version in the examples accordingly with the real version.
It is recommended to create a fresh clone of the repository to avoid any local files to interfere
in the process: