Document how to version the operator (not the CRD spec)

[adyanth]

What is the URL of the document?

https://sdk.operatorframework.io/docs/best-practices/best-practices/

Which section(s) is the issue in?

Development

What needs fixing?

The document does not talk about how to bump code versions of the Operator itself. I found that I have to make changes in the Makefile and change the image tag in bundle/manifests/cloudflare-operator.clusterserviceversion.yaml (3 places) and config/manager/kustomization.yaml. Is this how it should be done?

Additional context

[asmacdo]

This would be a great first issue! If anyone wants to pick this up and ask questions, @theishshah will explain it all!

[camilamacedo86]

To version your Operator itself the recommendation would be follow up seemver: https://semver.org/

Therefore, you will see that when you create a project you will build it and create an image, the image tag should be the Operator version. In this way, you see the Makefile: https://github.com/operator-framework/operator-sdk/blob/87cdc50247832a53e26b713a2ecab6e2215bdb52/testdata/go/v3/memcached-operator/Makefile#L1-L6

In this way, if you update the Makefile when you generate the bundle with make bundle the CSV will have the new version so you do not need to update it. See that the image used to build your Operator and its Operator Bundle image are also defined already: https://github.com/operator-framework/operator-sdk/blob/87cdc50247832a53e26b713a2ecab6e2215bdb52/testdata/go/v3/memcached-operator/Makefile#L27-L36

I think it would fit well better in the FAQ section: https://sdk.operatorframework.io/docs/faqs/ WDYT? Would you like to contribute with?

c/c @asmacdo @theishshah

[adyanth]

Hey @asmacdo @camilamacedo86 I sure can take a crack at adding this, FAQ sounds good. And following semvar is a good idea, yes.

I saw that the make bundle does it, but that is not needed unless publishing to the OLM right? That's where I was thinking if we can add another target (for manifests to depend on) so that when the version is updated in the Makefile, it automatically updates the image tag in the manifests.

[camilamacedo86]

Hi @adyanth,

I saw that the make bundle does it, but that is not needed unless publishing to the OLM right? That's where I was thinking if we can add another target (for manifests to depend on) so that when the version is updated in the Makefile, it automatically updates the image tag in the manifests.

What are the manifests which do not get updated when you follow the steps described in https://github.com/operator-framework/operator-sdk/issues/5524#issuecomment-1191262547? Sorry, I am not sure if I can follow up on your motivation. Could you please provide some examples?

[adyanth]

This command is what I believe updates the manifests: https://github.com/operator-framework/operator-sdk/blob/87cdc50247832a53e26b713a2ecab6e2215bdb52/testdata/go/v3/memcached-operator/Makefile#L187

This is only called during make bundle. What I propose is doing that for other make targets (like docker-build, etc) as well, since there is no need to use make bundle when not publishing to OLM. Or a separate make target for just that.

What does not get automated for me is the kustomize manifests without calling the bundle target.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten /remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen. Mark the issue as fresh by commenting /remove-lifecycle rotten. Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci[bot]]

@openshift-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen. Mark the issue as fresh by commenting /remove-lifecycle rotten. Exclude this issue from closing again by commenting /lifecycle frozen.

/close

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.