[kyuubi] branch release-doc created (now b8c5089df)

[ch...@apache.org]

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

chengpan pushed a change to branch release-doc
in repository https://gitbox.apache.org/repos/asf/kyuubi.git


      at b8c5089df [DOCS] Refine release process

This branch includes the following new commits:

     new b8c5089df [DOCS] Refine release process

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.

[kyuubi] 01/01: [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 release-doc
in repository https://gitbox.apache.org/repos/asf/kyuubi.git

commit b8c5089df6868f960b8dade1d1ceaa832ddc717b
Author: Cheng Pan <ch...@apache.org>
AuthorDate: Mon Feb 20 20:10:29 2023 +0800

    [DOCS] Refine release process
---
 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.