<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 10, 2020 at 11:28 AM Thomas Goirand <<a href="mailto:thomas@goirand.fr">thomas@goirand.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 6/10/20 3:23 PM, Jeremy Stanley wrote:<br>
> On 2020-06-10 15:11:35 +0200 (+0200), Thomas Goirand wrote:<br>
>> On 6/9/20 12:00 PM, Thierry Carrez wrote:<br>
> [...]<br>
>>> instead of doing a 14.0.0.0rc1 and then a 14.0.0.0rc2 that gets<br>
>>> promoted to 14.0.0, we would produce a 14.0.0, then a 14.0.1 and<br>
>>> just list that 14.0.1 in the release page at coordinated release<br>
>>> time.<br>
> [...]<br>
>> So more or less, you're removing the mandatory release of<br>
>> frozen-before-release artifact.<br>
>><br>
>> From a downstream distribution package maintainer, I'd like to<br>
>> voice my concern that with this scheme, it's going to be very<br>
>> complicated to deliver the OpenStack release on-time when it gets<br>
>> released. This also means that it will be difficult to get things<br>
>> like puppet-openstack fixed on-time too, because they depend on<br>
>> the packages.<br>
>><br>
>> So, while I don't really mind the beta releases anymore (I don't<br>
>> package them these days), I do strongly believe that the RC<br>
>> releases are convenient. I don't think we need RC2, RC3, etc, but<br>
>> having a working RC1 2 or 3 weeks before the release is really a<br>
>> good thing which I would regret a lot if we decided not to do it<br>
>> anymore.<br>
> <br>
> I don't understand what problem you're trying to convey. The<br>
> suggestion is basically a cosmetic change, where instead of<br>
> 14.0.0.0rc1 (and then if necessary 14.0.0.0rc2 and so on) we'd have<br>
> 14.0.0 (and then if necessary 14.0.1 and so on). How does that<br>
> change your packaging process? Is the concern that you can't know in<br>
> advance what the release version number for a given service is going<br>
> to be?<br>
<br>
I don't buy into the "this is only cosmetic": that's not what's going to<br>
happen, unfortunately. Obviously, in your example, 14.0.0 will *NOT* be<br>
considered a pre-release of the next stable. 14.0.0 will be seen as the<br>
"final release" version, ie: the first stable version. This means that<br>
we wont have tags for the pre-release.<br>
<br>
If the issue is just cosmetic as you say, then let's keep rc1 as the<br>
name for the pre-release version.<br>
<br>
Cheers,<br>
<br>
Thomas Goirand (zigo)<br><br></blockquote><div><br></div><div>I'm not seeing any issues with this downstream in Ubuntu. It'll be the same as handling openstack dependency releases today. Semantic versioning will tell you if it's bug fixes only. <br></div><div><br></div><div>Corey<br></div></div></div>