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: