only auto-bump kernel image version if kernel releases a stable version

[lmatz]

The kernel will start to release "release candidate" images before making it a stable version

For example, if the next release is v1.10.0, we will first release a v1.10.0-rc.1, maybe v1.10.0-rc.2 if necessary.
And eventually, after being battle-tested, we release v1.10.0.

We can have an agreement on the version naming that only v<number>.<number>.<number> is the stable version.
We will make any other images incompatible with this naming convention.

Although the GitHub Action is in Risingwave's Repository, let me make an issue here as it is auto-upgrading the version in the operator and helm-charts: https://github.com/risingwavelabs/risingwave/blob/main/.github/workflows/auto-update-helm-and-operator-version-by-release.yml

Let me filter non-stable version out by regex.

[arkbriar]

@Stab123 could you take a look?

[Stab123]

Ok, I will take a look later.

[lmatz]

I think I contradicted myself... 😓

We do want to have release candidate as the default image version when open-source users deploy RW via Risingwave-Operator.
This is part of the release strategy as we hope the release candidate version (which has been tested by us and gone through the release testing procedure) can be more battle-tested before we make it a stable version.

I apologize for the confusion and will close this issue.

[arkbriar]

Actually I think it makes sense since the manifests examples should only contain the latest stable versions. We should have internal pipelines for testing the RC instead of relying on the users.

[lmatz]

I assembled some thoughts on why we want to rely on users to test: https://www.notion.so/risingwave-labs/Reflection-on-Kernel-Release-6dd1ec53798749cab4854cf3998a9703 and posted under a thread of discussion on slack: https://risingwave-labs.slack.com/archives/C03KED89H88/p1716777167529289

internal pipelines for testing the RC
Internal pipelines are always and will be always executed before any major/minor/candidate release as long as it is public and shown on our release page: https://github.com/risingwavelabs/risingwave/releases
MIsfortunes happen from time to time.

By the convention of the release candidate version, we will have very strict control of cherry-picking new code into it unless it is really necessary and tests are accompanied. Most of the time, the stable version is expected to be exactly the same as the release candidate version.