This transition the victoria branch to extended maintenance.
Changes for bugfixes and things the team deems important are
still encouraged, but there will no longer be official releases
off of the branch.
A final release for victoria is proposed in the parent patch [1]
The transition deadline is April 27th, 2022.
[1] https://review.opendev.org/c/openstack/releases/+/836921
Change-Id: I584d9a58201b0a42ce4de7b4933aadf58319f84b
This generated patch adds missing victoria release note page link if
that page exists for a deliverable.
If any of your deliverables does not have a release note link added in
this patch, then please check whether there is an open patch on that
repository with the topic "reno-victoria" [1] still waiting to be
approved.
[1] https://review.opendev.org/q/topic:reno-victoria
Change-Id: I1463846c53d70cb845be2b278be55f6934c6ce77
Needs the depends-on as we are tagging that commit here for
puppet-tripleo. Mostly bumps bugfix except two that deserve
bumping .minor.
Depends-On: I2f514a1805933577173dfa57120e360cca05be10
Change-Id: I9495cb36a9ac8f8dcb225c2c5839ab7b53d341de
The related puppet-tripleo metadata bump in [1] is needed before
this can merge (gated by openstack-tox-validate). This also
creates a victoria branch for os-apply-config that was forgotten
in [2]
[1] I93e180221b3c589e4a54e926f2be6a27933d8448
[2] https://review.opendev.org/c/openstack/releases/+/760571
Change-Id: I46cd8a7b414c6884e311f2fbe9ff3b9a5d9e6bc1
In [1] we make victoria for tripleoclient and tripleo-common.
This adds the rest of our cycle-with-intermediary repos.
Related puppet-tripleo bump merged in [2].
[1] https://review.opendev.org/#/c/759449
[2] https://review.opendev.org/#/c/760113
Change-Id: I62cbe402067425fac335c5517f7d136f0f380dab
This is a tripleo release to coincide with RC1, but this is *not*
an RC in particular we are not cutting the victoria branch yet.
Related puppet-tripleo metadata bump at [1] has merged.
[1] https://review.opendev.org/754347
Change-Id: Ia2b655987b646b6d431892e22942ef1dc5849808
Cycle-trailing deliverables are regular cycle-following deliverables,
using RCs or not not using RCs -- they just have a different deadline.
Rather than using a release model, those deadline variants are better
described using deliverable types, in much the same way 'library'
deliverables have a specific deadline too.
This simplifies the list of models significantly, and allows to have
proposer validation of trailing deliverables that use RCs or not use
RCs.
For compatibility in old branches, setting 'cycle-trailing' is still
supported, it will just overload the type to 'trailing' if specified.
Change-Id: Ifce88ef3e5dd406f45f25214699f16e736ad5377