You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Anyway, I assume the underlying cause is that alphabetically, [ sorts before A, and there's no rule preventing naming your operator to (intentionally or unintentionally) take advantage of that.
Putting [Deprecated] at the start of the name of a deprecated operator's entry isn't ideal, but there isn't a "deprecated" field or similar in ClusterServiceVersion v1alpha1 that could be used specifically for this.
Perhaps recognising a deprecated value for the maturity free-string field would work? Or perhaps this is something that should be at the channel level instead, to deprecate a whole operator, rather than a specific version?
Anyway, with that metadata being distinguished, then deprecated operators could be hidden by default, and searched as a separate axis, and the deprecation status could be made visible via something other than the name field.
It seems that there is a well defined deprecated maturity value:
Originally reported by @TBBle in k8s-operatorhub/community-operators#549 (comment)
Looking at operatorhub.io, the top looks like this:
It seems that there is a well defined
deprecated
maturity value:operatorhub.io/frontend/src/utils/constants.ts
Lines 111 to 113 in e15615c
But it is not well documented for bundle authors.
Only places I find it mentioned are:
But not in https://docs.okd.io/4.9/operators/understanding/olm-what-operators-are.html#olm-maturity-model_olm-what-operators-are
The text was updated successfully, but these errors were encountered: