Upgrade Operator SDK version command

[mateusoliveira43]

trafficstars

Feature Request

Describe the problem you need a feature to resolve.

In the projects I work, we sometimes upgrade Operator SDK versions. The way to do it is to follow the docs (https://sdk.operatorframework.io/docs/upgrading-sdk-version/) and apply changes for each version bump, right?

I was wondering if a command to do this automatically can be created?

Describe the solution you'd like.

One possible solution would be to annotate how that code user wants to upgrade was created.

Example of what I am doing with a helm based opeartor:

Create operator code in two temp folders. One using current Operator SDK version, and the other using the version I want to upgrade to

operator-sdk init --plugins=helm --domain=<OPERATOR_DOMAIN> --project-name=<OPERATOR_NAME>
operator-sdk create api --helm-chart=<CHARTS_FOLDER>
operator-sdk generate kustomize manifests -q --interactive=false

Then, I create a diff file between this two temp folders

diff -ruN <current_version_directory> <next_version_directory>

And finally apply the diff to my operator code, using patch command. This part can be enhanced, sometimes the command does not fully succeed.

[varshaprasad96]

@mateusoliveira43 Thanks for opening this issue, and mentioning this idea. Upgrading SDK projects can sometimes be tricky, especially with breaking changes. In order to help with the process, in Kubebuilder (upstream for SDK) there has some work being done on an alpha-generate command (https://kubebuilder.io/migration/migration_guide_gov3_to_gov4.html#your-upgrade-assistant-the-alpha-generate-command). The slight difference here though is that this command is intended to be used while bumping plugin versions rather than the version of the binary itself. Which seems reasonable, as most of the user facing changes can be expected with scaffolding changes.

[varshaprasad96]

Keeping this issue open and leaving it for the community to discuss.

[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.