[kyuubi] branch branch-1.7 updated: [KYUUBI #4385] [DOCS] Refine release process

[ch...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

chengpan pushed a commit to branch branch-1.7
in repository https://gitbox.apache.org/repos/asf/kyuubi.git


The following commit(s) were added to refs/heads/branch-1.7 by this push:
     new bb7107954 [KYUUBI #4385] [DOCS] Refine release process
bb7107954 is described below

commit bb71079541fe03d2317a1180d10deefa5aaa45ad
Author: Cheng Pan <ch...@apache.org>
AuthorDate: Tue Feb 21 09:47:45 2023 +0800

    [KYUUBI #4385] [DOCS] Refine release process
    
    ### _Why are the changes needed?_
    
    Refine the release process docs, including
    
    - rename "major release" to "feature release", the latter is more meaningful
    - clarify the release manager should commit first, then go back to continue the rest release process.
    
    ### _How was this patch tested?_
    - [ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible
    
    - [x] Add screenshots for manual tests if appropriate
    <img width="1377" alt="image" src="https://user-images.githubusercontent.com/26535726/220105136-37b65fe6-0217-4e59-8736-9a0375da84c0.png">
    
    - [ ] [Run test](https://kyuubi.readthedocs.io/en/master/develop_tools/testing.html#running-tests) locally before make a pull request
    
    Closes #4385 from pan3793/release-doc.
    
    Closes #4385
    
    b8c5089d [Cheng Pan] [DOCS] Refine release process
    
    Authored-by: Cheng Pan <ch...@apache.org>
    Signed-off-by: Cheng Pan <ch...@apache.org>
    (cherry picked from commit 7eac6ea0f9437386d1ba2b58902269187e6a52c5)
    Signed-off-by: Cheng Pan <ch...@apache.org>
---
 docs/community/release.md | 46 ++++++++++++++++++++++++++++++++--------------
 1 file changed, 32 insertions(+), 14 deletions(-)

diff --git a/docs/community/release.md b/docs/community/release.md
index ffbdda9c1..163c575ff 100644
--- a/docs/community/release.md
+++ b/docs/community/release.md
@@ -43,7 +43,7 @@ The release process consists of several steps:
 
 1. Decide to release
 2. Prepare for the release
-3. Cut branch off for __major__ release
+3. Cut branch off for __feature__ release
 4. Build a release candidate
 5. Vote on the release candidate
 6. If necessary, fix any issues and go back to step 3.
@@ -153,12 +153,12 @@ gpg --keyserver hkp://keyserver.ubuntu.com --send-keys ${PUBLIC_KEY} # send publ
 gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys ${PUBLIC_KEY} # verify
 ```
 
-## Cut branch if for major release
+## Cut branch if for feature release
 
 Kyuubi use version pattern `{MAJOR_VERSION}.{MINOR_VERSION}.{PATCH_VERSION}[-{OPTIONAL_SUFFIX}]`, e.g. `1.7.0`.
-__Major Release__ means `MAJOR_VERSION` or `MINOR_VERSION` changed, and __Patch Release__ means `PATCH_VERSION` changed.
+__Feature Release__ means `MAJOR_VERSION` or `MINOR_VERSION` changed, and __Patch Release__ means `PATCH_VERSION` changed.
 
-The main step towards preparing a major release is to create a release branch. This is done via standard Git branching
+The main step towards preparing a feature release is to create a release branch. This is done via standard Git branching
 mechanism and should be announced to the community once the branch is created.
 
 > Note: If you are releasing a patch version, you can ignore this step.
@@ -171,29 +171,47 @@ After cutting release branch, don't forget bump version in `master` branch.
 
 > Don't forget to switch to the release branch!
 
-1. Set environment variables.
+- Set environment variables.
 
 ```shell
 export RELEASE_VERSION=<release version, e.g. 1.7.0>
 export RELEASE_RC_NO=<RC number, e.g. 0>
+export NEXT_VERSION=<e.g. 1.7.1>
 ```
 
-2. Bump version.
+- Bump version, and create a git tag for the release candidate.
+
+Considering that other committers may merge PRs during your release period, you should accomplish the version change
+first, and then come back to the release candidate tag to continue the rest release process.
+
+The tag pattern is `v${RELEASE_VERSION}-rc${RELEASE_RC_NO}`, e.g. `v1.7.0-rc0`
+
+> NOTE: After all the voting passed, be sure to create a final tag with the pattern: `v${RELEASE_VERSION}`
 
 ```shell
+# Bump to the release version
 build/mvn versions:set -DgenerateBackupPoms=false -DnewVersion="${RELEASE_VERSION}"
-
 git commit -am "[RELEASE] Bump ${RELEASE_VERSION}"
-```
 
-3. Create a git tag for the release candidate.
+# Create tag
+git tag v${RELEASE_VERSION}-rc${RELEASE_RC_NO}
 
-The tag pattern is `v${RELEASE_VERSION}-rc${RELEASE_RC_NO}`, e.g. `v1.7.0-rc0`
+# Prepare for the next development version
+build/mvn versions:set -DgenerateBackupPoms=false -DnewVersion="${NEXT_VERSION}-SNAPSHOT"
+git commit -am "[RELEASE] Bump ${NEXT_VERSION}-SNAPSHOT"
 
-> NOTE: After all the voting passed, be sure to create a final tag with the pattern: `v${RELEASE_VERSION}`
+# Push branch to apache remote repo
+git push apache
+
+# Push tag to apache remote repo
+git push apache v${RELEASE_VERSION}-rc${RELEASE_RC_NO}
+
+# Go back to release candidate tag 
+git checkout v${RELEASE_VERSION}-rc${RELEASE_RC_NO}
+```
 
-4. Package the release binaries & sources, and upload them to the Apache staging SVN repo. Publish jars to the Apache
-   staging Maven repo.
+- Package source and binary artifacts, and upload them to the Apache staging SVN repo. Publish jars to the Apache
+  staging Maven repo.
 
 ```shell
 build/release/release.sh publish
@@ -201,7 +219,7 @@ build/release/release.sh publish
 
 To make your release available in the staging repository, you must close the staging repo in the [Apache Nexus](https://repository.apache.org/#stagingRepositories). Until you close, you can re-run deploying to staging multiple times. But once closed, it will create a new staging repo. So ensure you close this, so that the next RC (if need be) is on a new repo. Once everything is good, close the staging repository on Apache Nexus.
 
-5. Generate a pre-release note from GitHub for the subsequent voting.
+- Generate a pre-release note from GitHub for the subsequent voting.
 
 Goto the [release page](https://github.com/apache/kyuubi/releases) and click the "Draft a new release" button, then it would jump to a new page to prepare the release.