feat: change release tags to vX.Y.Z. Fixes #5954 (#5974)

* Add runtime resource request for GPUs * clean up * Updated docks and add check * clean up * update after feedback * Clean up after feedback
kubeflow · Jul 8, 2021 · b57bbee · b57bbee
1 parent 22c4c44
commit b57bbee
Show file tree

Hide file tree

Showing 3 changed files with 21 additions and 15 deletions.
diff --git a/RELEASE.md b/RELEASE.md
@@ -23,15 +23,15 @@ additionally.
 
 ## Release Tags and Branches
 
-Releases are tagged with tags like `X.Y.Z`, e.g. `1.0.2`. A special format like
-`1.0.0-rc.2` is a pre-release. It is the second release candidate before
-releasing the final `1.0.0`.
+Releases are tagged with tags like `vX.Y.Z`, e.g. `v1.0.2`. A special format like
+`v1.0.0-rc.2` is a pre-release. It is the second release candidate before
+releasing the final `v1.0.0`.
 
 A release branch has the name structure `release-X.Y` where `X.Y` stands for the
-minor version. Releases like `X.Y.Z` will all be released from the branch
+minor version. Releases like `vX.Y.Z` will all be released from the branch
 `release-X.Y`.
 
-For example, `1.0.2` release should be on `release-1.0` branch.
+For example, `v1.0.2` release should be on `release-1.0` branch.
 
 ## Contributor Instructions
 
@@ -171,11 +171,11 @@ If not, contact the KFP team to determine if the failure(s) would block the rele
 Note, when releasing from master, all the below mentions of "release branch" means master branch.
 
 1. Choose the release's complete `$VERSION` following semantic versioning, e.g.
-    - `1.0.0-rc.1`
-    - `1.0.0-rc.2`
-    - `1.0.0`
-    - `1.0.1`
-    - `1.1.0`
+    - `v1.0.0-rc.1`
+    - `v1.0.0-rc.2`
+    - `v1.0.0`
+    - `v1.0.1`
+    - `v1.1.0`
     - ...
     Contact @Bobgy if you are not sure what next version should be.
 
@@ -248,7 +248,7 @@ fill in the description. Detailed steps:
 
    1. [Draft a new release](https://github.com/kubeflow/pipelines/releases/new).
    1. Typing in version tag field to search and select the "$VERSION" tag published in release instructions above.
-   Its format is like `X.Y.Z` or `X.Y.Z-rc.N`.
+   Its format is like `vX.Y.Z` or `vX.Y.Z-rc.N`.
 
    1. Use this template for public releases and replace the `$VERSION` with real values.
 

diff --git a/test/release/README.md b/test/release/README.md
@@ -4,18 +4,18 @@ For full release documentation, please read [RELEASE.md](../../RELEASE.md).
 
 To do a release:
 
-TAG=`<TAG>` BRANCH=`<BRANCH>` make release
+TAG=`<TAG>` BRANCH=`<BRANCH>` make release, the release needs to start with `v` to support [golang version handling](https://golang.org/ref/mod#versions)
 
 Example, release in release branch:
 
 ```bash
-    TAG=1.4.0 BRANCH=release-1.4 make release
+    TAG=v1.4.0 BRANCH=release-1.4 make release
 ```
 
 Example, release an RC (release candidate) in master branch:
 
 ```bash
-    TAG=2.0.0-rc.1 BRANCH=master make release
+    TAG=v2.0.0-rc.1 BRANCH=master make release
 ```
 
 ## Dev guide

diff --git a/test/release/release.sh b/test/release/release.sh
@@ -20,6 +20,12 @@ TAG=$1
 BRANCH=$2
 REPO=kubeflow/pipelines
 
+if  [[ $TAG != v* ]] ;
+then
+    echo "release tag needs to start with 'v' "
+    exit 1
+fi
+
 if [[ -z "$BRANCH" || -z "$TAG" ]]; then
   echo "Usage: ./test/release/release.sh <release-tag> <release-branch>" >&2
   exit 1
@@ -37,7 +43,7 @@ cd "$clone_dir"
 git checkout "$BRANCH"
 
 echo "Preparing local git tags used by changelog generation."
-# tags with "-" are pre-releases, e.g. 1.0.0-rc.1
+# tags with "-" are pre-releases, e.g. v1.0.0-rc.1
 if [[ "$TAG" =~ "-" ]]; then
   echo "Releasing a pre-release $TAG."
 else