Improve Spark Operator release process

[andreyvelich]

As we discussed on our recent call, we want to improve Spark Operator release process to follow Kubernetes best-practices for releases. We want to maintain stable releases for Spark Operator and have an ability to cherry-pick bug fixes to the release branch.

We can follow similar release process as for Kubeflow Katib and Kubeflow Training Operator.
For that, we propose the following:

• For each release we will create a new release branch release-1.x
• When we want to make a new release or release candidate we will appropriately tag the release branch.
  • For example for release 1.5 we will create the release-1.5 branch. When we make the first RC, we will add tag v1.5.0-rc.0 to the release-1.5 branch. When we make the first release: v1.5.0, we will add tag v1.5.0 to the release-1.5 branch.
• Spark Operator images will be tagged appropriately when we make a release. E.g.
  • docker.io/kubeflow/spark-operator:v1.5.0-rc.0
  • docker.io/kubeflow/spark-operator:v1.5.0
  • docker.io/kubeflow/spark-operator:v1.5.1

Also, we don't want to maintain separate releases for the Helm charts and keep only 1 version for the Spark Operator image in the Charts. As an example, we can check the KServe Helm Charts where Helm charts have the same version as KServe Controller image.

/good-first-issue
/cc @vara-bonthu @yuchaoran2011

[google-oss-prow]

@andreyvelich:
This request has been marked as suitable for new contributors.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue command.

In response to this:

As we discussed on our recent call, we want to improve Spark Operator release process to follow Kubernetes best-practices for releases. We want to maintain stable releases for Spark Operator and have an ability to cherry-pick bug fixes to the release branch.

We can follow similar release process as for Kubeflow Katib and Kubeflow Training Operator.
For that, we propose the following:

• For each release we will create a new release branch release-1.x
• When we want to make a new release or release candidate we will appropriately tag the release branch.
  • For example for release 1.5 we will create the release-1.5 branch. When we make the first RC, we will add tag v1.5.0-rc.0 to the release-1.5 branch. When we make the first release: v1.5.0, we will add tag v1.5.0 to the release-1.5 branch.
• Spark Operator images will be tagged appropriately when we make a release. E.g.
  • docker.io/kubeflow/spark-operator:v1.5.0-rc.0
  • docker.io/kubeflow/spark-operator:v1.5.0
  • docker.io/kubeflow/spark-operator:v1.5.1

Also, we don't want to maintain separate releases for the Helm charts and keep only 1 version for the Spark Operator image in the Charts. As an example, we can check the KServe Helm Charts where Helm charts have the same version as KServe Controller image.

/good-first-issue
/cc @vara-bonthu @yuchaoran2011

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.