<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 7, 2020 at 11:43 AM Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</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">Sean McGinnis wrote:<br>
>>>> Thanks for the detailed response Sean. I don't have an issue with the<br>
>>>> cycle model - Ironic is still tied to the cyclical release model. The<br>
>>>> part that I disagree with is the requirement to create an intermediary<br>
>>>> release. It shouldn't be a problem if bifrost doesn't make a feature<br>
>>>> release between Train and Ussuri, we'll just do a final Ussuri<br>
>>>> release. It's the intermediary I'd like to be optional, rather than<br>
>>>> the final cycle release.<br>
>>>><br>
>>> I would suggest switching these to cycle-with-rc then. There is one<br>
>>> release candidate that has to happen just before the final release for<br>
>>> the cycle, but that's mainly to make sure everything is in good shape<br>
>>> before we declare it done. That sounds like it might fit better with<br>
>>> what the team wants to do here.<br>
>> But what if we want to create a feature release mid-cycle? Some cycles<br>
>> we do, some we don't.<br>
>><br>
> With cycle-with-rc, that does allow *beta* releases to be done at any<br>
> point during the cycle. But those would be marked as b1, b2, etc.<br>
> releases. This allows those that want to try out upcoming features to<br>
> grab them if they want them, but would prevent anyone else from<br>
> accidentally picking up something before it is quite ready.<br>
> <br>
> I'm guessing this might not be what you are looking for though.<br>
> <br>
> We do have another release model called cycle-automatic. This was<br>
> introduced for tempest plugins to just do a release at the end of the<br>
> cycle to make sure there is a tag to denote the tempest version the<br>
> plugin was originally developed for. Since some plugins are being picked<br>
> up more often downstream, this model does allow for additional releases<br>
> to be proposed at any point during the development cycle.<br>
> <br>
> We will need to discuss this as a team to see if this makes sense for<br>
> non-tempest plugins. It was intended only for those types of<br>
> deliverables. I just mention it here as something that we do have in<br>
> place that might be adapted to fit what the team needs. But we also need<br>
> to consider what we are communicating to downstream consumers of our<br>
> releases, so I'm not entirely sure at this point if it makes sense, or<br>
> would be a good thing, to allow other types of deliverables to use this<br>
> model.<br>
<br>
Yeah the general idea was to drive toward best practices (if you do a <br>
single release per cycle, it's important that it's good, so it should <br>
use feature freeze, release candidates...). That said today it's rare <br>
that we break things... and nobody tests RC releases anyway.<br></blockquote><div><br></div><div>Unfortunately yes :(<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
So there is definitely a possibility for just having one single <br>
cycle-based release model: release once or more in a cycle, do not use <br>
betas or RCs. And if there is no release like two weeks before final, <br>
we'd cut automatically cut one from HEAD.<br></blockquote><div><br></div><div>I'd warmly welcome this.</div><div><br></div><div>Dmitry<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I'd actually prefer that to switching to cycle-independent, since <br>
deliverables under that model are not part of "the openstack release".<br>
<br>
That said, it might be a bit late to roll that out for this cycle, two <br>
days before we actually feature-freeze cycle-with-rc projects...<br>
<br>
-- <br>
Thierry Carrez (ttx)<br>
<br>
</blockquote></div></div>