<div dir="ltr">Hi Carl<br><br><div class="gmail_quote"><div dir="ltr">On Thu, 19 May 2016 at 21:51 Carl Baldwin <<a href="mailto:carl@ecbaldwin.net">carl@ecbaldwin.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, May 19, 2016 at 7:09 AM, Doug Hellmann <<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>> wrote:<br>
> We have the same issue with version numbers regressing no matter when we<br>
> cut the next release, so it's up to the team. It might be easier to deal<br>
> with now while it's fresh in our minds.<br>
><br>
> I would like to update the instructions that were followed to give<br>
> better information about version numbers. Can someone point me to the<br>
> documentation that was used for the release process?<br>
<br>
Hi, they are here [1].  Built from here [2].<br>
<br>
Carl<br></blockquote><div><br></div><div>Any update on re-tagging the mitaka release of networking-l2gw with the correct semantic version?  I'm working on packaging updates for Debian and Ubuntu, and don't really want to push in 2016.1.0, only to have to then bump the epoch (versioning semantic in Debian for dealing with changes in versioning that result in out of order versions) again once the next semantically versioned release comes out.</div><div><br></div><div>Also, what are networking-l2gw's plans for Newton?  I also manage the packaging of vmware-nsx, which amongst other things, depends on networking-l2gw so it would be nice to have a co-ordinated release of networking-l2gw, vmware-nsx (and networking-sfc and tap-as-a-service - but I'll start another thread on that).</div><div><br></div><div>Cheers</div><div><br></div><div>James</div></div></div>