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

Thomas Goirand zigo at debian.org
Wed Jun 10 13:11:35 UTC 2020

On 6/9/20 12:00 PM, Thierry Carrez wrote:
> 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. New releases could be pushed to the release branch to include
> late bugfixes or translation updates, until final release date. So
> instead of doing a and then a that gets promoted
> to 14.0.0, we would produce a 14.0.0, then a 14.0.1 and just list that
> 14.0.1 in the release page at coordinated release time.

tl;dr: If we do that, I wont be releasing packages the day of the
release, and wont be able to get puppet-openstack for Debian ready on
time either.


So more or less, you're removing the mandatory release of
frozen-before-release artifact.

>From a downstream distribution package maintainer, I'd like to voice my
concern that with this scheme, it's going to be very complicated to
deliver the OpenStack release on-time when it gets released. This also
means that it will be difficult to get things like puppet-openstack
fixed on-time too, because they depend on the packages.

So, while I don't really mind the beta releases anymore (I don't package
them these days), I do strongly believe that the RC releases are
convenient. I don't think we need RC2, RC3, etc, but having a working
RC1 2 or 3 weeks before the release is really a good thing which I would
regret a lot if we decided not to do it anymore.


Thomas Goirand (zigo)

More information about the openstack-discuss mailing list