[Development] Branches and time based releases

Oswald Buddenhagen oswald.buddenhagen at digia.com
Fri Mar 7 11:59:30 CET 2014

On Thu, Mar 06, 2014 at 08:46:19AM +0100, Knoll Lars wrote:
> On 27/02/14 11:28, "Oswald Buddenhagen" <oswald.buddenhagen at digia.com> wrote:
> >to sum up: we agree with lars' proposal, except on this point. lars,
> >feel like changing your mind?
> Ok, let’s try it and see what happens. We can always adjust as we go
> forward.

> Most other projects do however cherry-pick into their releases (that’s
> also what linux distributions do when they add patches to their packages).
i don't think making our own release team a downstream is a particularly
good idea. we've seen how well that goes before, with the symbian and
maemo productization teams being the peak of in-house release absurdity.
we should strive for integrating the release team into the development
process to ensure that problems are properly addressed, not worked
around. that's best done by directly targeting the release branch.

> >the next question would be how we proceed with implementing the change.
> >i guess branching off 5.3 from stable and merging stable for the time
> >being would be the best approach.
> I think we’re through the merge hazzle with stable now, so I’d keep that
> branch until 5.3.0. Once we have 5.3.0 out, let’s aim for renaming stable
> to 5.3 and move over to that.
the natural point for naming a branch is obviously the time it is
created. for 5.3 that time has passed. the next chance for a try with a
fresh branch will be creating 5.3.0 instead of downmerging to release.
renaming stable around that time is pretty much arbitrary - we can just
do that whenever the CI team is able to set it up. so what it comes down
to is saying "let's get started with it" and seeing when it is ready
(which may very well be next week).

More information about the Development mailing list