Release Process

The following procedure should be used to create a new release of the Kabanero operator. Some of the steps will vary depending on the kind of release being produced. The following types of releases are used by Kabanero, and assume an x.y.z version identifier which is semver-compatible:

• Minor releases, where the 'y' component of the version changes, and the 'z' component is zero.
• Patch releases, where the 'z' component of the version changes. Sometimes this is referred to as a "z-release".
• Pre-releases, where the version is followed by '-alpha.a' or '-rc.a'

The release procedure:

1. If necessary, for a minor release, create a release branch. This would be necessary when master contains changes that should not be included in the minor release stream. The branch should be created on the commit before the un-desired changes, and should be named release-0.y where y is the minor version.
2. Verify the versions of dependent components. Currently these include the CLI service, the landing page and kabanero eventing. Typically these components would produce a release before the operator produces its release.
3. Update config/version.yaml to include a top-level section for the new version, if it does not already have one. Any suffix to the x.y.z version should not be included on the top level version (ie 0.4.0-alpha.1 becomes 0.4.0).
4. Update config/version.yaml to include the new versions of dependencies.
5. Update config/version.yaml to default to the new version.
6. Update config/samples/default.yaml to use the new release of collections and the new release of Kabanero.
7. Update config/samples/full.yaml to use the new release of collections and the new release of Kabanero. For each dependent component, update the override information to point to the related container images for the new release of Kabanero.
8. Commit and push these changes to master, or the release branch.
9. Create the release on the release tab. The release name should be the semver name of the release. For pre-releases, be sure to check the pre-release box on the release page. The release description should contain a list of the component versions included in this release of Kabanero. For pre-releases, the description should contain a comment about the date after which the artifacts will be deleted.
10. If the release was created in a release branch, roll the changes forward to other (later) release branches, and master.

The post-release procedure (preparing for the next release):

1. In Makefile, change the CURRENT_RELEASE to be the next release. In master, this would be the next minor release. In a release branch, this would be the next patch release.
2. Copy the Kabanero CRDs into the previous release's OLM directory. For example, if changing from 0.3.0 to 0.4.0, copy the Kabanero CRDs into registry/manifests/kabanero-operator/0.3.0
3. Create a new directory and CSV for the next release of Kabanero. The CSV will need to be modified to include the new version number. The CSV replaces field needs to change to be the previous release.
4. In config/version.yaml, create a new top level section for the next release, but do not make it the default yet.