[all][release] One following-cycle release model to bind them all

Thomas Goirand zigo at debian.org
Wed Jun 10 13:17:50 UTC 2020


On 6/10/20 11:46 AM, Thierry Carrez wrote:
> Mark Goddard wrote:
>> [...]
>> One substantial change here is that there will no longer be a period
>> where the stable branch exists but the coordinated release does not.
>> This could be an issue for cycle trailing projects such as kolla which
>> sometimes get blocked on external (and internal) factors. Currently we
>> are able to revert master from it's temporary stable mode to start
>> development for the next cycle, while we continue stabilising the
>> stable branch for release.
> 
> Making sure I understand... Currently you are using RC1 to create the
> stable branch, but it's not really a "release candidate", it's more a
> starting point for stabilization ? So you can have a broken master
> branch, tag it RC1 and create stable/ussuri from it, then work on making
> stable/ussuri releasable while keeping master broken ?
> 
> If I understand correctly, then it's a fair point: the new model
> actually makes release candidates real release candidates, so it does
> not really support having a master branch that never gets close to
> releasable state. I would argue that this was not really the intent
> before with RC1 tags, but it certainly made it easier to hide.
> 
> To support your case more clearly, maybe we could allow creating stable
> branches from arbitrary commit SHAs.

This doesn't work, because downstream users of the upstream code have no
way to know what upstream considers as the frozen-working-version. With
RC1, we do know.

Again, can we have a middle-ground where we have only a SINGLE rc
release before the final one? For downstream distros (like Debian) I'd
be easy to integrate patches to fix problems on top of this unique RC.

Last, the RC doesn't have to be cut out of a stable branch. If that is
the issue (ie: backporting to the stable branch before the release is a
high cost), then the RC could be cut from master... Whatever is the best
workflow upstream, I don't mind, as long as we have pre-release to eat
for 1/ downstream distro 2/ config-management projects like Kola / OSA /
puppet-openstack.

Cheers,

Thomas Goirand (zigo)



More information about the openstack-discuss mailing list