[RFC] Release branches for unity-system-compositor

Daniel van Vugt daniel.van.vugt at canonical.com
Thu Jul 23 01:35:19 UTC 2015

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.

On 22/07/15 22:16, Alan Griffiths wrote:
> On 22/07/15 15:11, Cemil Azizoglu wrote:
>>>> It's not true that if we don't have release branches,
>> ​release
>>  is coupled
>> ​ 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.

More information about the Mir-devel mailing list