chore(update): Updating Channel to trigger an Operator Update #469
Conversation
Co-authored-by: Fortune-Ndlovu <[email protected]>
Co-authored-by: nickboldt <[email protected]>
Fortune-Ndlovu
temporarily deployed
to
external
GitHub Actions
Inactive
| @@ -42,7 +42,7 @@ metadata: | |||
| features.operators.openshift.io/token-auth-gcp: "false" | |||
| repository: https://gitlab.cee.redhat.com/rhidp/rhdh/ | |||
| support: Red Hat | |||
| skipRange: '>=1.0.0 <1.3.2' | |||
| skipRange: '>=1.2.0 <1.3.2' | |||
There was a problem hiding this comment.
while valid, why do we need to change this?
There was a problem hiding this comment.
Starting from 1.0.0 means a direct update from, say, 1.1.0 to 1.3.2, no? Could this be an issue, knowing the possible breaking changes that might happen across minor versions of the operand? Would it make more sense to allow some kind of "progressive" minor upgrades?
There was a problem hiding this comment.
Yes, direct updates from earlier versions like 1.1.0 to 1.3.2 could introduce issues. To address this, I am maintaining the replaces field 1.2.5 -> 1.3.2 and ensuring the skipRange limits upgrades to versions within the 1.2.x series.
|
please link to the JIRA for this change. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: nickboldt The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Description
Which issue(s) does this PR fix or relate to
https://issues.redhat.com/browse/RHIDP-4687
PR acceptance criteria
rhdh-operator.clusterserviceversion.yamlfile accordinglyHow to test changes / Special notes to the reviewer