[all][release] One following-cycle release model to bind them all
thierry at openstack.org
Thu Jun 11 10:23:27 UTC 2020
Mark Goddard wrote:
>> [Excerpt from Thierry's original post yesterday...]
>>>> The "final" release would be marked by creating a release
>>>> (stable) branch, and that would need to be done before a
>>>> deadline. Like today, that deadline depends on whether that
>>>> deliverable is a library, a client library, a release-trailing
>>>> exception or just a regular part of the common release.
>>>> The main change this proposal introduces would be to stop having
>>>> release candidates at the end of the cycle. Instead we would
>>>> produce a release, which would be a candidate for inclusion in
>>>> the coordinated OpenStack release.
>> For service projects, that "deadline" he talks about would be the
>> start of the traditional RC period, we just wouldn't use special rc1
>> tags for branching at that point, we'd use actual version numbers to
>> branch from. I think the proposal has probably confused some folks
>> by saying, "stop having release candidates [...and instead have a]
>> candidate for inclusion in the coordinated OpenStack release." It
>> would basically still be a "release candidate" in spirit, just not
>> in name, and not using the same tagging scheme as we have
>> traditionally used for release candidates of service projects.
> I think this is reading between the lines somewhat. I agree that it
> makes sense however, and preserves the period before release during
> which every deliverable to be included in GA should have a release
To clarify, the intent is definitely to keep a stabilization period
between the moment the branch is created and the "final" coordinated
We currently do it by asking projects to release a "RC1" which coincides
with the branching, and then have them iterate on tagging further RCx
versions (usually just one). The last available version at coordinated
release date is re-tagged as a "normal" release number.
With the unified model, projects would create the stabilization branch
when they feel like it, then iterate on tagging versions (usually just
one). The last available version at coordinated release date is
considered included in the "OpenStack" release, without the need for a
Also to clarify, we are /already/ using that model for all
cycle-with-intermediary deliverables like Swift or Ironic or Karbor or
Vitrage or Monasca or CloudKitty or Horizon... It's not as if it was a
new thing that would break packagers workflows. They already support it.
If anything, it simplifies the workflow by making everything available
ahead of time, rather than artificially trigger a bunch of new versions
on release day as we re-tag the final RCs into correct release numbers.
Thierry Carrez (ttx)
More information about the openstack-discuss