<div dir="ltr">Hi Ihar<br><br><div class="gmail_quote"><div dir="ltr">On Mon, 8 Aug 2016 at 10:37 Ihar Hrachyshka <<a href="mailto:ihrachys@redhat.com">ihrachys@redhat.com</a>> wrote:</div><div dir="ltr"><span style="line-height:1.5">[...]</span></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Any update on re-tagging the mitaka release of networking-l2gw with the<br>
> correct semantic version?  I'm working on packaging updates for Debian<br>
> and Ubuntu, and don't really want to push in 2016.1.0, only to have to<br>
> then bump the epoch (versioning semantic in Debian for dealing with<br>
> changes in versioning that result in out of order versions) again once<br>
> the next semantically versioned release comes out.<br>
><br>
<br>
(Hey, neutron release liaison here.)<br></blockquote><div><br></div><div>Hey!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I was thinking we will stick to the (unfortunate) versioning for the<br>
subproject for the time of Mitaka. But I am happy to switch versioning if<br>
it makes someone’s life easier. Though I would like to hear a confirmation<br>
on that from l2gw folks first. (I added some cores to CC.)<br></blockquote><div><br></div><div>1.0.0 -> 2016.1.0 -> 3.0.0 is the trick here as 3.0.0 < 2016.1.0; its possible but I'd rather avoid the epochs in packaging if possible (I might just skip 2016.1.0 and use a 1.0.0+git snapshot version instead to avoid that situation).</div><div><br>So I can be flexible, but I suspect that this versioning inconsistency will cause other deployment types issues as well.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Also, what are networking-l2gw's plans for Newton?  I also manage the<br>
> packaging of vmware-nsx, which amongst other things, depends on<br>
> networking-l2gw so it would be nice to have a co-ordinated release of<br>
> networking-l2gw, vmware-nsx (and networking-sfc and tap-as-a-service -<br>
> but I'll start another thread on that).<br>
<br>
Note that neither vmware-nsx nor taas is part of neutron stadium, and as<br>
such are not managed by neutron-release team. You would need to coordinate<br>
with them separately.<br></blockquote><div><br></div><div>OK - I missed they are not part of neutron stadium ([0]); I'll hookup with those teams individually (already in contact with the vmware-nsx team anyway).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There was a thread on SFC lately asking for Mitaka release. I guess we<br>
don’t have any stable branches so far for the subproject.</blockquote><div><br></div><div>Yeah - started a different thread on that one.</div><div><br></div><div>Cheers</div><div><br></div><div>James</div><div><br></div><div>[0] <a href="http://docs.openstack.org/developer/neutron/stadium/sub_projects.html#official-sub-project-list">http://docs.openstack.org/developer/neutron/stadium/sub_projects.html#official-sub-project-list</a> </div></div></div>