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
Copy file name to clipboardExpand all lines: modules/understanding-upgrade-channels.adoc
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -62,15 +62,15 @@ You can imagine seeing the following releases in your channel:
62
62
* {product-version}.3
63
63
* {product-version}.4
64
64
65
-
The service recommends only updates that have been tested and have no known serious regressions. For example, if your cluster is on {product-version}.1 and {product-title} suggests {product-version}.4, then it is recommended to update from {product-version}.1 to {product-version}.4.
65
+
The service recommends only updates that have been tested and have no known serious regressions. For example, if your cluster is on {product-version}.1 and {product-title} suggests {product-version}.4, then it is recommended to update from {product-version}.1 to {product-version}.4.
66
66
67
67
[IMPORTANT]
68
68
====
69
69
Do not rely on consecutive patch numbers. In this example, {product-version}.2 is not and never was available in the channel, therefore updates to {product-version}.2 are not recommended or supported.
70
70
====
71
71
72
72
[id="conditional-updates-overview_{context}"]
73
-
== Update recommendation removals and Condtional Updates
73
+
== Update recommendation removals and Conditional Updates
74
74
Red Hat monitors newly released versions and update paths associated with those versions before and after they are added to supported channels. If a serious regression is identified, Red Hat may remove affected update recommendations. When Red Hat chooses to remove update recommendations, that action is taken in all relevant channels simultaneously. The removal of recommended updates may happen either before or after updates have been promoted to supported channels.
75
75
76
76
If Red Hat removes update recommendations from any supported release, a superseding update recommendation will be provided to a future version that corrects the regression. There may however be a delay while the defect is corrected, tested, and promoted to your selected channel.
@@ -91,7 +91,7 @@ First, select the minor version you want for your cluster upgrade. Selecting a c
91
91
Due to the complexity involved in planning upgrades between versions many minors apart, channels that assist in planning upgrades beyond a single EUS-to-EUS update are not offered.
92
92
====
93
93
94
-
Second, you should choose your desired rollout strategy. You may choose to update as soon as Red Hat declares a release GA by selecting from fast channels or you may want to wait for Red Hat to promote releases to the stable channel. Update recommendations offered in the `fast-{product-version}` and `stable-{product-version}` are both fully supported and benefit equally from ongoing data analysis. The promotion delay before promoting release to the stable channel represets the only difference between the two channels. Updates to the latest z-streams are generally promoted to the stable channel within a week or two, however the delay when initially rolling out updates to the latest minor is much longer, generally 45-90 days. Please consider the promotion delay when choosing your desired channel as waiting for promotion to the stable channel may affect your scheduling plans.
94
+
Second, you should choose your desired rollout strategy. You may choose to update as soon as Red Hat declares a release GA by selecting from fast channels or you may want to wait for Red Hat to promote releases to the stable channel. Update recommendations offered in the `fast-{product-version}` and `stable-{product-version}` are both fully supported and benefit equally from ongoing data analysis. The promotion delay before promoting release to the stable channel represents the only difference between the two channels. Updates to the latest z-streams are generally promoted to the stable channel within a week or two, however the delay when initially rolling out updates to the latest minor is much longer, generally 45-90 days. Please consider the promotion delay when choosing your desired channel as waiting for promotion to the stable channel may affect your scheduling plans.
95
95
96
96
Additionally, there are several factors which may lead an organization to move clusters to the fast channel either permanently or temporarily including:
0 commit comments