Change the release script and documentation to bump the minor version…

… instead of micro version. (IBM#698)

* minor logging/refinement changes to release script

Signed-off-by: David Wood <[email protected]>

* bump minor instead of micro version in release-branch.sh

Signed-off-by: David Wood <[email protected]>

* change release pr branch to pending-releases/vx.y.z

Signed-off-by: David Wood <[email protected]>

* comments/logging in release-branch.sh

Signed-off-by: David Wood <[email protected]>

* updated RELEASE.md to match recent changes to release-branch.sh

Signed-off-by: David Wood <[email protected]>

* release documentation

Signed-off-by: David Wood <[email protected]>

---------

Signed-off-by: David Wood <[email protected]>

RELEASE.md

@@ -16,13 +16,17 @@ allows intermediate publishing from the main branch using version X.Y.Z.dev\<N\>
 1. Building and publishing is done manually, or soon via a git action, in the branch created by `scripts/release-branch.sh`. 
  1. Wheels can only be published once to pypi for a given version.
  1. Transform and kfp images may be republished to the docker registry.
+1. Releases done via the `release-branch.sh` script will have their micro version number set to 0 (e.g., 1.2.0)
+1. Intermediate releases that bump the micro version may be done by individual transforms. This can mean
+that version X.Y.Z of a transform is equivalent to the X.Y+1.0 release. The latter created when running
+the `release-branch.sh` script.
 
 ## Cutting the release
 Creating the release involves
 
-1. Edit the `release-notes.md` to list major/minor changes
+1. Editing the `release-notes.md` to list major/minor changes and commit to the main branch.
 1. Creating a release branch and updating the main branch versions (using `release-branch.sh`).
-1. Creating a github release and tag from the release branch.
+1. Creating a github release and tag from the release branch using the github web UI.
 1. Building and publishing pypi library wheels and docker registry image.
 
 Each is discussed below.
@@ -36,19 +40,21 @@ Commit this to the main branch so it is ready for including in the release branc
 The `scripts/release-branch.sh` is currently run manually to create the branch and tags as follows:
 
 1. Creates the `releases/vX.Y.Z` from the main branch where `X.Y.Z` are defined in .make.versions
-1. Creates the `vX.Y.Z` branch for PR'ing back into the `releases/vX.Y.Z` branch. 
-1. In the new `vX.Y.Z` branch 
+1. Creates the `pending-releases/vX.Y.Z` branch for PR'ing back into the `releases/vX.Y.Z` branch. 
+1. In the new `pending-releases/vX.Y.Z` branch 
  1. Nulls out the version suffix in the new branch's `.make.version` file. 
  1. Applies the unsuffixed versions to the artifacts published from the repo using `make set-versions`..
  1. Commits and pushes branch 
 1. Creates the `pending-version-change/vX.Y.Z` branch for PR'ing back into the main branch.
+ * Note: this branch is named with the new release version (i.e. vX.Y.Z), however
+ the version in this branch is actually X.Y+1.0.dev0.
 1. In the `pending-version-change/vX.Y.Z` branch
  1. Increments the minor version (i.e. Z+1) and resets the suffix to `dev0` in `.make.versions`.
  1. Commits and pushes branch 
 
 To double-check the version that will be published from the release,
 ```
-git checkout vX.Y.Z 
+git checkout pending-releases/vX.Y.Z 
 make show-version
 ```
 This will print for example, 1.2.3. 
@@ -60,7 +66,7 @@ scripts/release-branch.sh
 ```
 
 After running the script, you should
-1. Create a pull request from branch `vX.Y.Z` into the `releases/vX.Y.Z` branch, and merge.
+1. Create a pull request from branch `pending-releases/vX.Y.Z` into the `releases/vX.Y.Z` branch, and merge.
 2. Use the github web UI to create a git release and tag of the `releases/vX.Y.Z` branch
 3. Create a pull request from branch `pending-version-change/vX.Y.Z` into the main branch, and merge. 
 

scripts/release-branch.sh

@@ -24,7 +24,7 @@ else
  tag=test$version
 fi
 release_branch=releases/$tag
-release_branch_pr=$tag
+release_branch_pr=pending-releases/$tag
 
 # Create a new branch for this version and switch to it
 if [ ! -z "$debug" ]; then
@@ -66,46 +66,53 @@ git push
 
 # Now create and push a new branch from which we will PR into main to update the version 
 this_version=$(make show-version)
-next_version_branch=pending-version-change/$this_version
-echo Creating $next_version_branch branch for PR request back to $DEFAULT_BRANCH for version upgrade
-git checkout -b $next_version_branch 
-git push --set-upstream origin $next_version_branch
+next_version_branch_pr=pending-version-change/$this_version
+echo Creating $next_version_branch_pr branch for PR request back to $DEFAULT_BRANCH for version upgrade
+git checkout -b $next_version_branch_pr 
+git push --set-upstream origin $next_version_branch_pr
 git commit --no-verify -s -a -m "Initializing branch to PR back into $DEFAULT_BRANCH holding the next development version"
 git push 
 
-# Change to the next development version (bumped minor version with suffix).
-micro=$(cat .make.versions | grep '^DPK_MICRO_VERSION=' | sed -e 's/DPK_MICRO_VERSION=\([0-9]*\).*/\1/') 
-micro=$(($micro + 1))
-cat .make.versions | sed -e "s/^DPK_MICRO_VERSION=.*/DPK_MICRO_VERSION=$micro/" \
+# Change to the next development version (bump minor version with reset suffix).
+minor=$(cat .make.versions | grep '^DPK_MINOR_VERSION' | sed -e 's/DPK_MINOR_VERSION[ ]*=[ ]*\([0-9]*\).*/\1/') 
+minor=$(($minor + 1))
+cat .make.versions | sed -e "s/^DPK_MINOR_VERSION=.*/DPK_MINOR_VERSION=$minor/" \
+ -e "s/^DPK_MICRO_VERSION=.*/DPK_MICRO_VERSION=0/" \
  -e "s/^DPK_VERSION_SUFFIX=.*/DPK_VERSION_SUFFIX=.dev0/" > tt
 mv tt .make.versions
 next_version=$(make show-version)
 
 # Apply the version change to all files in the repo 
-echo Applying updated version $next_version to $next_version_branch branch
+echo Applying updated version $next_version to $next_version_branch_pr branch
 make set-versions > /dev/null
 
 # Push the version change back to the origin
 if [ -z "$debug" ]; then
- echo Committing and pushing version $next_version to $next_version_branch branch.
- git commit --no-verify -s -a -m "Bump micro version to $next_version" 
- #git diff origin/$next_version_branch $next_version_branch 
+ echo Committing and pushing version $next_version to $next_version_branch_pr branch.
+ git commit --no-verify -s -a -m "Bump version to $next_version" 
+ #git diff origin/$next_version_branch_pr $next_version_branch_pr 
  git push 
 else
  git status
- echo In non-debug mode, the above diffs would have been committed to the $next_version_branch branch
+ echo In non-debug mode, the above diffs would have been committed to the $next_version_branch_pr branch
 fi
+
+# Return to the main branch
+git checkout $DEFAULT_BRANCH
+
 cat << EOM
 
 Summary of changes:
- 1. Pushed $release_branch_pr branch holding version $version of the repository. 
+ 1. Pushed temporary $release_branch_pr branch holding version $version of the repository. 
  2. Pushed $release_branch branch to receive PR from the $release_branch_pr branch.
- 3. Pushed $next_version_branch branch to hold updated version $next_version of the repository on the main branch. 
- No modifications made to the $DEFAULT_BRANCH branch.
+ 3. Pushed temporary $next_version_branch_pr branch to hold updated version $next_version of the repository on the main branch. 
+ No modifications were made to the $DEFAULT_BRANCH branch.
 
 To complete this process, please go to https://github.com/IBM/data-prep-kit and ...
- 1. Create a new pull request from the $next_version_branch branch back into $DEFAULT_BRANCH branch. 
+ 1. Create a new pull request from the $next_version_branch_pr branch back into $DEFAULT_BRANCH branch. 
  2. Create a pull request from $release_branch_pr branch into $release_branch branch.
  3. After the PR into $release_branch is merged, create a new tag $tag on $release_branch branch.
  4. Create a release from the $tag tag
+ 5. Once all PRs are merged, you may delete the $release_branch_pr and $next_version_branch_pr branches.
 EOM
+git status