osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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?
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200610/19108eee/attachment.sig>