Amend release-cadence-adjustment resolution

This contains minor adjustments due to feedback for the preceeding
resolution.

Change-Id: I1b7c5485ecae0e64a8a942da4bf0ea816b7c38f9
This commit is contained in:
Dan Smith 2022-02-25 14:32:49 -08:00
parent f498019cf7
commit 9623399f06

View File

@ -5,7 +5,7 @@
History History
------- -------
Openstack has historically used a six month release cycle cadence for OpenStack has historically used a six month release cycle cadence for
the projects which participate in the coordinated release. Further, the projects which participate in the coordinated release. Further,
upgrades were tested and supported between two adjacent coordinated upgrades were tested and supported between two adjacent coordinated
releases only, requiring deployers and distributions to either upgrade releases only, requiring deployers and distributions to either upgrade
@ -118,9 +118,13 @@ Details
schema from tick-tick. This includes data migrations which need to schema from tick-tick. This includes data migrations which need to
do work in tick releases, and while they may do work in tock do work in tick releases, and while they may do work in tock
releases, the work done in tock releases cannot be releases, the work done in tock releases cannot be
*mandatory*. This can be solved by requiring operators to *mandatory*. This can be solved (as it is today) by requiring
(force-)complete data migrations on a source tick before upgrading operators to (force-)complete data migrations on a supported
to a target tick, for example. release before moving to one that drops compatibility. The
tick-tock arrangement described in this resolution would require
attention to those migrations to make sure they happen
(automatically or manually) on the source tick before upgrading to
the target tick, for example.
Example sequence Example sequence
---------------- ----------------