What

While we have a release process and it is reasonably light weight. I think there are some improvements we can make that will improve the quality of life of the person coordinating the release and make it a more easily understood and stable process.

Possible flow outline:

Key goal here is to remove the need for inputting versions of components over and over again.

Minor

1. create release-v1.x branch with a release only file that contains the versions for this release. We somewhat have this in the release.mk file but this is generated by the inputs rather than just committing it directly. If we want to keep the release.mk file possibly it could be re-used or import the new file?

AUTHORINO_OPERATOR_VERSION=0.16.0
LIMITADOR_OPERATOR_VERSION=0.12.1
DNS_OPERATOR_VERSION=0.12.0
WASM_SHIM_VERSION=0.8.1
CONSOLEPLUGIN=0.0.18
CHANNELS=stable
KUADRANT_VERSION=1.1.0 # should also work with -rc1 for example

Check this in and push it to the remote.
2) Trigger GH workflow that uses the release-v1.x branch (this should be the only needed input)

• generate the bundle based on the versions provided
• update the catalog under config/deploy/olm to point to the catalog image
• generate any needed helm bits
• commit the changes
• create the release tag and release in GH

3. once the release tag is created it should auto trigger a build of the images. This should also use this file to generate the image urls and tags. It should be possible to re-run this workflow if needed. Again the only input should be the release branch to use to generate the images.

Patch
For a patch release it should just be the same other than creating a release-v1.x branch. New code changes should be added to the needed release branch (ideally from cherry-picks from main), updating any needed version bumps and re-running the release workflow from the release-v1.x branch.

In the workflow the first step should be to output the commit hash, the branch name and the versions that will be used in this release.

** note on the release.mk file **
At this point lets say if the file doesn't exist, then fall back to latest.

• Define the new release doc
• Implement what is required to bring it to reality
• Test the flow with a "dev" type release