Open Stack

On Wed, 10 Jun 2020 at 14:24, Jeremy Stanley <fungi at yuggoth.org> wrote:
>
> On 2020-06-10 15:11:35 +0200 (+0200), Thomas Goirand wrote:
> > On 6/9/20 12:00 PM, Thierry Carrez wrote:
> [...]
> > > instead of doing a 14.0.0.0rc1 and then a 14.0.0.0rc2 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.
> [...]
> > 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.
>
> I don't understand what problem you're trying to convey. The
> suggestion is basically a cosmetic change, where instead of
> 14.0.0.0rc1 (and then if necessary 14.0.0.0rc2 and so on) we'd have
> 14.0.0 (and then if necessary 14.0.1 and so on). How does that
> change your packaging process? Is the concern that you can't know in
> advance what the release version number for a given service is going
> to be?

I think the issue is that currently there is a period of time in which
every project has a release candidate which can be packaged and
tested, prior to the release. In the new model there is no obligation
to release anything prior to GA, and I expect most teams would not.

> --
> Jeremy Stanley