Expected handling of minor release updates

[lulf]

Type of question

About best practices for CSV and release management.

Question

When maintaining multiple minor versions of an operator and updating those due to CVE updates etc, what is the best practices for the .spec.replaces field when supporting multiple major.minor versions?

I.e. lets assume the following releases are made (in order)

• version 1.1.0
• version 1.2.0 (with replaces: 1.1.0)

Now, if a version 1.1.1 needs to be released, what should the replaces point to? It clearly replaces 1.1.0, but it doesn't replace 1.2.0.

What is the effect of specifying/not specifying replaces?

Should the replaces only cover the latest micro of a particular minor?

[Bowenislandsong]

Hi @lulf, I think you would benefit from the design document that describes Replaces / Channels. The rest of that document should help describe the best practice for designing your operator upgrades.

[lulf]

Hi @Bowenislandsong, that document was helpful, thanks!

So, would I model my scenario as having a channel per minor? I.e.

channel: 1.1
csv: 1.1.0
csv: 1.1.1 (replaces 1.1.0)
channel: 1.2
csv: 1.2.0 (replaces 1.1.0)

I'm struggling to understand how a user would get upgraded from 1.1.1 to 1.2.0.

Or is my scenario simply not supported?

[Bowenislandsong]

Your scenario seems fine. Subscribers might have to change channels in this way. An alternative can be that you create a third channel to define 1.1.0 -> 1.1.1 -> 1.2.0. It all depends on how you would want your subscribers to consume your operator. You are in full control over your upgrade paths and alternatives.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.