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 https://github.com/k8s-operatorhub/community-operators/issues/549#issue-1095081779
Looking at operatorhub.io, the top looks like this:
It seems that there is a well defined
deprecatedmaturity value:https://github.com/k8s-operatorhub/operatorhub.io/blob/e15615c96e78c7fed452529334beb83ff9f484f2/frontend/src/utils/constants.ts#L111-L113
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