Skip to content

Commit e4806dc

Browse files
authored
docs: 1 year wait time for upgrading (#36784)
Follow-up to #36782
1 parent f59eeb8 commit e4806dc

1 file changed

Lines changed: 1 addition & 1 deletion

File tree

  • doc/user/content/self-managed-deployments/upgrading

doc/user/content/self-managed-deployments/upgrading/_index.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -234,7 +234,7 @@ The behavior of the new version rollout follows your `rolloutStrategy` setting.
234234
#### *WaitUntilReady* - ***Default***
235235

236236
`WaitUntilReady` creates a new generation of pods and automatically cuts over to them as soon as they catch up to the old generation and become `ReadyToPromote`. This strategy temporarily doubles the required resources to run Materialize.
237-
{{< warning >}} `WaitUntilReady` waits up to 72 hours (configurable by the `with_0dt_deployment_max_wait` flag) for the new pods to become ready. If the promotion has not occurred by then, the new pods are automatically promoted. {{< /warning >}}
237+
{{< warning >}} `WaitUntilReady` waits up to 1 year (configurable by the `with_0dt_deployment_max_wait` flag) for the new pods to become ready. If the promotion has not occurred by then, the new pods are automatically promoted. {{< /warning >}}
238238

239239
#### *ImmediatelyPromoteCausingDowntime*
240240
{{< warning >}} Using the `ImmediatelyPromoteCausingDowntime` rollout flag will cause downtime. {{< /warning >}}

0 commit comments

Comments
 (0)