Bug 1921778

> This yields  `v1.0.0-1.2.3 < v1.0.0-1.1.55` which is then mapped back to `v1.2.3+1.2.3 < v.1.2.3+1.1.55`

Does it follow the typical semver precedence rules? If yes, I guess it should be `v1.0.0-1.1.55 < v1.0.0-1.2.3`, right?

Sorry, I couldn't reproduce this issue with an old opm. For example, am I missing something? Or what's the difference between opm and the build command in http://pub.devel.redhat.com/pub/task/340215/log/stdout.log?
 
[root@preserve-olm-env data]# opm index add -b registry.stage.redhat.io/openshift-istio/kiali-operator-metadata:2.3-1 -f registry-proxy.engineering.redhat.com/rh-osbs/iib-pub-pending:v4.7 -t registry-proxy.engineering.redhat.com/rh-osbs/iib-pub-pending:v4.7-bug --overwrite-latest
INFO[0000] building the index                            bundles="[registry.stage.redhat.io/openshift-istio/kiali-operator-metadata:2.3-1]"
INFO[0000] Pulling previous image registry-proxy.engineering.redhat.com/rh-osbs/iib-pub-pending:v4.7 to get metadata  bundles="[registry.stage.redhat.io/openshift-istio/kiali-operator-metadata:2.3-1]"
INFO[0000] resolved name: registry-proxy.engineering.redhat.com/rh-osbs/iib-pub-pending:v4.7  bundles="[registry.stage.redhat.io/openshift-is
...
...
INFO[0020] [podman build --format docker -f index.Dockerfile879176593 -t registry-proxy.engineering.redhat.com/rh-osbs/iib-pub-pending:v4.7-bug .]  bundles="[registry.stage.redhat.io/openshift-istio/kiali-operator-metadata:2.3-1]"

[root@preserve-olm-env data]# opm version
Version: version.Version{OpmVersion:"v1.14.3-94-g6183dbb", GitCommit:"6183dbb", BuildDate:"2021-02-04T09:33:47Z", GoOs:"linux", GoArch:"amd64"}

It works well too with the olm opm:
- `registry-proxy.engineering.redhat.com/rh-osbs/iib-pub-pending:v4.5`
- `registry-proxy.engineering.redhat.com/rh-osbs/iib-pub-pending:v4.6` 

registry.stage.redhat.io/openshift-service-mesh/istio-rhel8-operator-metadata:2.0.1.1-6

Hi Jian,

So the problem that we ran into here is that there is one operator in the stage index that was using buildId as part of its versioning. So it was explicitly *not* using semantic versioning. This generally isn't a problem in replaces mode except in the case where bundles are batch added as a set into an index all at once (which happens either when you pass several bundles into an index add command or whenever using --overwrite-latest). So, this edge case is specifically when buildId is set on two bundles in a given channel and the version is otherwise identical.

more detail here: https://github.com/operator-framework/operator-registry/pull/571#issue-563493254

Basically, the fix here is that we now consider buildId when attempting to internally decide what order to insert a set of bundles when more than one is passed in.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: OpenShift Container Platform 4.8.2 bug fix and security update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2021:2438