OLMv1 4.16: Support legacy OLM upgrade constraint semantics

operators/olm_v1/olmv1-installing-an-operator-from-a-catalog.adoc

@@ -13,7 +13,7 @@ In the current Technology Preview release of {olmv1-first}, you manage catalogs
 :FeatureName: {olmv1}
 include::snippets/technology-preview.adoc[]
 
-[id="prerequisites_olmv1-installing-an-operator-from-a-catalog"]
+[id="prerequisites_{context}"]
 == Prerequisites
 
 * Access to an {product-title} cluster using an account with `cluster-admin` permissions
@@ -69,11 +69,45 @@ include::modules/olmv1-updating-an-operator.adoc[leveloffset=+1]
 * xref:../../operators/olm_v1/olmv1-installing-an-operator-from-a-catalog.adoc#olmv1-about-target-versions_olmv1-installing-operator[Example custom resources (CRs) that specify a target version]
 * xref:../../operators/olm_v1/olmv1-installing-an-operator-from-a-catalog.adoc#olmv1-version-range-comparisons_olmv1-installing-operator[Version comparison strings]
 
-include::modules/olmv1-semver-support.adoc[leveloffset=+2]
+[id="upgrade-constraint-semantics_{context}"]
+== Upgrade constraint semantics
+
+When determining upgrade edges for an installed cluster extension, {olmv1-first} supports {olmv0} semantics starting in {product-title} 4.16. This support follows the behavior from {olmv0}, including `replaces`, `skips`, and `skipRange` directives, with a few noted differences.
+
+By supporting {olmv0} semantics, {olmv1} now honors the upgrade graph from catalogs accurately.
+
+.Differences from original {olmv0} implementation
+
+* If there are multiple possible successors, {olmv1} behavior differs in the following ways:
+** In {olmv0}, the successor closest to the channel head is chosen.
+** In {olmv1}, the successor with the highest semantic version (semver) is chosen.
+
+* Consider the following set of file-based catalog (FBC) channel entries:
++
+[source,yaml]
+----
+# ...
+- name: example.v3.0.0
+  skips: ["example.v2.0.0"]
+- name: example.v2.0.0
+  skipRange: >=1.0.0 <2.0.0
+----
++
+If `1.0.0` is installed, {olmv1} behavior differs in the following ways:
++
+--
+** {olmv0-caps} will not see an upgrade edge to `v2.0.0` because `v2.0.0` is skipped and not on the `replaces` chain.
+** {olmv1} will see the upgrade edge because {olmv1} does not have a concept of a `replaces` chain. {olmv1} finds all entries that have a `replace`, `skip`, or `skipRange` value that covers the currently installed version.
+--
+
+[NOTE]
+====
+Support for semantic versioning (semver) upgrade constraints was introduced in {product-title} 4.15 but disabled in 4.16 in favor of {olmv0} semantics during this Technology Preview phase.
+====
 
 [role="_additional-resources"]
 .Additional resources
-* xref:../../operators/olm_v1/olmv1-installing-an-operator-from-a-catalog.adoc#olmv1-forcing-an-update-or-rollback_olmv1-installing-operator[Forcing an update or rollback]
+* xref:../../operators/understanding/olm/olm-workflow.adoc#olm-upgrades_olm-workflow[{olmv0-caps} upgrade semantics]
 
 include::modules/olmv1-version-range-support.adoc[leveloffset=+2]