[RFC] Release branches for unity-system-compositor

[Cemil Azizoglu]

I'm going to abstain (and maybe mildly dissent).

​>​
 * Decouples trunk from the release process, i.e., we don't need
    to temporarily freeze trunk to release from it.

​
It's not true that if we don't have release branches,
​release
 is coupled
​ with the development process​
.
​​


>​
* Allows us to handle multiple versions more cleanly and effectively
    (e.g., fix a bug in a particular released version).

We can always create a branch retroactively and land from that.

More branches mean more complexity, more wait time.

Cemil


On Wed, Jul 22, 2015 at 3:47 AM, Gerry Boland <gerry.boland at canonical.com>
wrote:

> No objection here
> -G
>
> On 22/07/15 02:08, Daniel van Vugt wrote:
> > +1
> >
> > On 21/07/15 18:00, Alexandros Frantzis wrote:
> > > Hi all,
> > >
> > > in the Mir project we are following the standard practice of forking
> off
> > > a new branch from trunk for each (minor) release. The benefits of this
> > > approach are well known, but to summarize, the main points are:
> > >
> > >    * Decouples trunk from the release process, i.e., we don't need
> > >      to temporarily freeze trunk to release from it.
> > >    * Allows us to handle multiple versions more cleanly and effectively
> > >      (e.g., fix a bug in a particular released version).
> > >
> > > For the reasons mentioned above, I propose that we move to the same
> > > scheme for unity-system-compositor too. At the moment,
> > > unity-system-compositor does not follow this model, instead having a
> > > trunk and single packaging/release branch, tracking the latest released
> > > version.
> > >
> > > We can select any version scheme that suits us, but one recommendation
> > > is that we bump the main version number (whichever we decide that to
> > > be), and therefore create a new version branch, at least every time USC
> > > is changed to use a newer server or client API/ABI.
> > >
> > > In other words, if we use the minor version as the main version, we
> want
> > > to guarantee that all releases 0.x.y will continue to work with the
> same
> > > mir library ABIs that 0.x.0 was originally released against. This
> scheme
> > > makes it straightforward to manage updates/fixes for released versions
> > > as point releases.
> > >
> > > Thanks,
> > > Alexandros
> > >
> >
>
>
> --
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>



-- 
Cemil Azizoglu
Mir Display Server - Team Lead
Canonical USA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20150722/5eed46c3/attachment.html>