Subject: [RFC] Release branches for unity-system-compositor

From: Alexandros Frantzis <[email-masked]>
Date: Tue, 21 Jul 2015 13:00:16 +0300

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

---

From: Alan Griffiths <[email-masked]>
Date: Tue, 21 Jul 2015 11:03:39 +0100

On 21/07/15 11:00, Alexandros Frantzis wrote:
> I propose that we move to the same
> scheme for unity-system-compositor too.

+1

---

From: Kevin DuBois <[email-masked]>
Date: Tue, 21 Jul 2015 07:32:11 -0400

Sounds like it'll make usc management easier, +1.

On Tue, Jul 21, 2015 at 6:03 AM, Alan Griffiths <
[email-masked]> wrote:

> --
> Mir-devel mailing list
> [email-masked]
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>

---

From: Christopher James Halse Rogers <[email-masked]>
Date: Tue, 21 Jul 2015 19:59:23 +0800

+1

-- 
Sent using Dekko from my Ubuntu device

---

From: Daniel van Vugt <[email-masked]>
Date: Wed, 22 Jul 2015 09:08:11 +0800

+1

---

From: Gerry Boland <[email-masked]>
Date: Wed, 22 Jul 2015 09:47:15 +0100

No objection here
-G

---

From: Cemil Azizoglu <[email-masked]>
Date: Wed, 22 Jul 2015 09:11:47 -0500

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

​>​

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

>​

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

More branches mean more complexity, more wait time.

Cemil

-- 
Cemil Azizoglu
Mir Display Server - Team Lead
Canonical USA

---

From: Alan Griffiths <[email-masked]>
Date: Wed, 22 Jul 2015 15:16:17 +0100

> ​ with the development process​

In theory. In practice we have USC feature branches that we're not
landing on trunk until the 0.14 release is done.

---

From: Daniel van Vugt <[email-masked]>
Date: Thu, 23 Jul 2015 09:35:19 +0800

Indeed multi-series development is an overlapping activity.

If you consider the Mir 0.14.0 release we're trying to get out the door 
right now, most of what's gone into that is dated 1 May to 23 June (tags 
br0.13..br0.14). That does not mean the team has been sitting on their 
hands since 23 June.

To keep the team moving seamlessly we just branched 0.14 around 23 June 
so that work on lp:mir (0.15) can keep going at full speed while 
simultaneously providing a "freeze" point for the 0.14.0 release to 
stabilise in its own branch. And just as well because we've (anpok) been 
trying to fix and release 0.14 for a month so far. If we were trying to 
release from lp:mir the situation would be even more fluid and it would 
be much more difficult to stabilise and release.

Branches are free and cheap. And they improve team productivity as well 
as code reliability. All you need to manage them is a keen eye on your 
bug tracker to accurately represent the status of the different 
branches, and fortunately we have the best tool in the world for that, 
with Launchpad.