<div dir="ltr">I think it makes a lot of sense to make them independent, especially since the releases often contain security fixes, so that they should be included in any older supported releases of Horizon as well.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 3, 2020 at 3:02 PM Sean McGinnis <<a href="mailto:sean.mcginnis@gmx.com">sean.mcginnis@gmx.com</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 3/3/20 4:11 AM, Akihiro Motoki wrote:<br>
> Thanks Thierry for the detail explanation.<br>
> The horizon team will update the corresponding repos for new minor<br>
> releases and follow the usual release process.<br>
> One question: we have passed the milestone-2. Is it better to wait<br>
> till Victoria dev cycle is open?<br>
><br>
> Thanks,<br>
> Akihiro<br>
<br>
We are past the deadline for inclusion in ussuri. But that said, these<br>
are things that are currently being used by the team, so I think it's a<br>
little misleading in its current state. I think we should get these new<br>
releases done in this cycle if possible.<br>
<br>
Part of this is also the assumption that these will be cycle based. I<br>
wonder if this are more appropriate as independent deliverables? That<br>
means they are not tied to a specific release cycle and can be released<br>
whenever there is something to be released. At least something to think<br>
about.<br>
<br>
<a href="https://releases.openstack.org/reference/release_models.html#cycle-with-intermediary" rel="noreferrer" target="_blank">https://releases.openstack.org/reference/release_models.html#cycle-with-intermediary</a><br>
<br>
> On Fri, Feb 28, 2020 at 1:47 AM Thierry Carrez <<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>> wrote:<br>
>> Thierry Carrez wrote:<br>
>>> The way we've been handling this in the past was to ignore past releases<br>
>>> (since they are not signed by the release team), and push a new one<br>
>>> through the releases repository. It should replace the unofficial one in<br>
>>> PyPI and make sure all is in order.<br>
>> Clarification with a practical example:<br>
>><br>
>> xstatic-hogan 2.0.0.2 is on PyPI, but has no tag in the<br>
>> openstack/xstatic-hogan repo, and no deliverable file in openstack/releases.<br>
>><br>
>> Solution is to resync everything by proposing a 2.0.0.3 release that<br>
>> will have tag, be in openstack/releases and have a matching upload on PyPI.<br>
>><br>
>> This is done by:<br>
>><br>
>> - bumping BUILD at<br>
>> <a href="https://opendev.org/openstack/xstatic-hogan/src/branch/master/xstatic/pkg/hogan/__init__.py#" rel="noreferrer" target="_blank">https://opendev.org/openstack/xstatic-hogan/src/branch/master/xstatic/pkg/hogan/__init__.py#</a><br>
>><br>
>> - adding a deliverables/_independent/xstatic-hogan.yaml file in<br>
>> openstack/releases defining a tag for 2.0.0.3<br>
>><br>
>> - removing the "deprecated" line from<br>
>> <a href="https://opendev.org/openstack/governance/src/branch/master/reference/projects.yaml#L542" rel="noreferrer" target="_blank">https://opendev.org/openstack/governance/src/branch/master/reference/projects.yaml#L542</a><br>
>><br>
>> Repeat for every affected package :)<br>
>><br>
>> --<br>
>> Thierry Carrez (ttx)<br>
>><br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Radomir Dopieralski</div></div></div></div></div>