[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