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
Support for link:https://semver.org/[semantic versioning (semver)] is enabled in {olmv1} by default. Operator and extension authors can use the semver standard to define compatible updates.
5
+
// Moved to _unused_topics dir with 4.16 in case useful in a later release of OLMv1.
12
6
13
-
{olmv1-first} can use an Operator or extension's version number to determine if an update can be resolved successfully.
14
-
15
-
Cluster administrators can define a range of acceptable versions to install and automtically update. For Operators and extensions that follow the semver standard, you can use comparison strings to define to specify a desired version range.
16
-
17
-
[NOTE]
18
-
====
19
-
{olmv1} does not support automatic updates to the next major version. If you want to perform a major version update, you must verify and apply the update manually. For more information, see "Forcing an update or rollback".
20
-
====
7
+
:_mod-docs-content-type: CONCEPT
21
8
22
-
== Major version zero releases
9
+
[id="olmv1-major-version-zero_{context}"]
10
+
= Major version zero releases
23
11
24
12
The semver standard specifies that major version zero releases (`O.y.z`) are reserved for initial development. During the initial development stage, the API is not stable and breaking changes might be introduced in any published version. As a result, major version zero releases apply a special set of update conditions.
// Moved to _unused_topics dir with 4.16 in case useful in a later release of OLMv1.
6
+
7
+
:_mod-docs-content-type: CONCEPT
8
+
9
+
[id="olmv1-semver-support_{context}"]
10
+
= Support for semantic versioning
11
+
12
+
{olmv1-first} supports link:https://semver.org/[semantic versioning (semver)] when explicitly enabled. Cluster extension authors can use the semver standard to define compatible updates.
13
+
14
+
[NOTE]
15
+
====
16
+
In {product-title} 4.16, {olmv1} uses {olmv0} semantics by default.
17
+
====
18
+
19
+
{olmv1} can use an extension's version number to determine if an update can be resolved successfully.
20
+
21
+
Cluster administrators can define a range of acceptable versions to install and automatically update. For extensions that follow the semver standard, you can use comparison strings to specify a desired version range.
22
+
23
+
[NOTE]
24
+
====
25
+
{olmv1} does not support automatic updates to the next major version. If you want to perform a major version update, you must verify and apply the update manually. For more information, see "Forcing an update or rollback".
Copy file name to clipboardExpand all lines: modules/olmv1-version-range-comparisons.adoc
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -97,7 +97,7 @@ You can make patch release comparisons by using the tilde (`~`) comparison opera
97
97
98
98
|===
99
99
100
-
You can use the caret (`^`) comparison operator to make a comparison for a major release. If you use a major release comparison before the first stable release is published, the minor versions define the API's level of stability. In the semantic versioning (SemVer) specification, the first stable release is published as the `1.0.0` version.
100
+
You can use the caret (`^`) comparison operator to make a comparison for a major release. If you make a major release comparison before the first stable release is published, the minor versions define the API's level of stability. In the semantic versioning (semver) specification, the first stable release is published as the `1.0.0` version.
* 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]
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.
76
+
77
+
By supporting {olmv0} semantics, {olmv1} now honors the upgrade graph from catalogs accurately.
78
+
79
+
.Differences from original {olmv0} implementation
80
+
81
+
* If there are multiple possible successors, {olmv1} behavior differs in the following ways:
82
+
** In {olmv0}, the successor closest to the channel head is chosen.
83
+
** In {olmv1}, the successor with the highest semantic version (semver) is chosen.
84
+
85
+
* Consider the following set of file-based catalog (FBC) channel entries:
86
+
+
87
+
[source,yaml]
88
+
----
89
+
# ...
90
+
- name: example.v3.0.0
91
+
skips: ["example.v2.0.0"]
92
+
- name: example.v2.0.0
93
+
skipRange: >=1.0.0 <2.0.0
94
+
----
95
+
+
96
+
If `1.0.0` is installed, {olmv1} behavior differs in the following ways:
97
+
+
98
+
--
99
+
** {olmv0-caps} will not see an upgrade edge to `v2.0.0` because `v2.0.0` is skipped and not on the `replaces` chain.
100
+
** {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.
101
+
--
102
+
103
+
[NOTE]
104
+
====
105
+
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.
106
+
====
73
107
74
108
[role="_additional-resources"]
75
109
.Additional resources
76
-
* 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]
0 commit comments