Katib release process

/kind feature

Background:

Katib wants to release manifests, in its various releases. Now that manifests live inside upstream app repos, the final result should be committed in this repo, not kubeflow/manifests. In this issue, I will describe a procedure to release manifests and make sure that release changes don’t affect master.

Describe the solution you’d like

Here is the procedure: Suppose we have a repo with kustomizations under manifests. Here are the steps that the upstream repository must take:

1. Create a new release branch:

VERSION="1.0"
git checkout -b release-$VERSION origin/master

1. Edit files under manifests (e.g., Deployments) to the release image tag. This can be done manually or with a sed command:

TAG=$VERSION
# Example with sed or manually
find manifests -type f | sed -i "s/<old_image_tag>/$TAG/g"

1. Commit changes to the release branch and tag commit as version:

git commit -s -a -m "Release $VERSION"
git tag $VERSION
git push -u origin release-$VERSION
git push $VERSION

1. Create GitHub release from existing tag and add desired release notes.

cc @andreyvelich

[andreyvelich]

I have a question about how to use katib 0.11 in kubeflow 1.3, should we create release-1.3 for kubeflow 1.3 or release-0.11?

We will run make release BRANCH=release-0.11 TAG=v0.11.0 for this release. So the first Katib release for Kubeflow 1.3 will be v0.11.0

[gaocegege]

I have a question about how to use katib 0.11 in kubeflow 1.3, should we create release-1.3 for kubeflow 1.3 or release-0.11?