<div dir="ltr"><div class="gmail_default" style="font-size:small">I'm going to abstain (and maybe mildly dissent).</div><div class="gmail_default" style="font-size:small"><br></div><span style="font-size:12.8000001907349px"><div class="gmail_default" style="font-size:small;display:inline">​>​</div> * Decouples trunk from the release process, i.e., we don't need</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">    to temporarily freeze trunk to release from it.</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px"><div class="gmail_default" style="font-size:small;display:inline"><br></div></span><div><span style="font-size:12.8000001907349px"><div class="gmail_default" style="font-size:small;display:inline">​</div></span>It's not true that if we don't have release branches, <div class="gmail_default" style="font-size:small;display:inline">​release</div> is coupled<div class="gmail_default" style="font-size:small;display:inline">​ with the development process​</div>.<div class="gmail_default" style="font-size:small;display:inline">​​</div><br><div class="gmail_default"><br></div><span style="font-size:12.8000001907349px"><div class="gmail_default" style="font-size:small;display:inline">>​</div>* Allows us to handle multiple versions more cleanly and effectively</span><br style="font-size:12.8000001907349px"><div class="gmail_default" style="font-size:small"><span style="font-size:12.8000001907349px">    (e.g., fix a bug in a particular released version).</span></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">We can always create a branch retroactively and land from that.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">More branches mean more complexity, more wait time.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Cemil</div><div class="gmail_default" style="font-size:small"><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 22, 2015 at 3:47 AM, Gerry Boland <span dir="ltr"><<a href="mailto:gerry.boland@canonical.com" target="_blank">gerry.boland@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">No objection here<br>
<span class="HOEnZb"><font color="#888888">-G<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 22/07/15 02:08, Daniel van Vugt wrote:<br>
> +1<br>
><br>
> On 21/07/15 18:00, Alexandros Frantzis wrote:<br>
> > Hi all,<br>
> ><br>
> > in the Mir project we are following the standard practice of forking off<br>
> > a new branch from trunk for each (minor) release. The benefits of this<br>
> > approach are well known, but to summarize, the main points are:<br>
> ><br>
> >    * Decouples trunk from the release process, i.e., we don't need<br>
> >      to temporarily freeze trunk to release from it.<br>
> >    * Allows us to handle multiple versions more cleanly and effectively<br>
> >      (e.g., fix a bug in a particular released version).<br>
> ><br>
> > For the reasons mentioned above, I propose that we move to the same<br>
> > scheme for unity-system-compositor too. At the moment,<br>
> > unity-system-compositor does not follow this model, instead having a<br>
> > trunk and single packaging/release branch, tracking the latest released<br>
> > version.<br>
> ><br>
> > We can select any version scheme that suits us, but one recommendation<br>
> > is that we bump the main version number (whichever we decide that to<br>
> > be), and therefore create a new version branch, at least every time USC<br>
> > is changed to use a newer server or client API/ABI.<br>
> ><br>
> > In other words, if we use the minor version as the main version, we want<br>
> > to guarantee that all releases 0.x.y will continue to work with the same<br>
> > mir library ABIs that 0.x.0 was originally released against. This scheme<br>
> > makes it straightforward to manage updates/fixes for released versions<br>
> > as point releases.<br>
> ><br>
> > Thanks,<br>
> > Alexandros<br>
> ><br>
><br>
<br>
<br>
--<br>
Mir-devel mailing list<br>
</div></div><div class="HOEnZb"><div class="h5"><a href="mailto:Mir-devel@lists.ubuntu.com">Mir-devel@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/mir-devel" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/mir-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Cemil Azizoglu<div>Mir Display Server - Team Lead</div><div>Canonical USA</div></div></div>
</div>