[Releasing] [Development] Qt 4.8.1 open source release date approaching..

[joao.abecasis at nokia.com]

I think we have way uglier things than cherry-picks in our history tree, and repeated commits are just a natural part of branching. Sure, we can *aim* for a cleaner history, but let's not unnecessarily restrict ourselves to one.

In the release/rc branch approach, the final release is incrementally approached. As part of the release process it should be tagged and the release branch merged back to mainline, so the release commit and tag become part of the main branch's history.

Traditionally, I don't think we've done a proper merge from the release branch, but more like a git merge -s ours, discarding changes in the release branch. I assume this was done for the sake of the release manager's sanity...

Cheers,


João

________________________________________
From: development-bounces+joao.abecasis=nokia.com at qt-project.org [development-bounces+joao.abecasis=nokia.com at qt-project.org] on behalf of Buddenhagen Oswald (Nokia-MP/Berlin)
Sent: 09 March 2012 20:54
To: development at qt-project.org; releasing at qt-project.org
Subject: Re: [Development] [Releasing] Qt 4.8.1 open source release date approaching..

On Fri, Mar 09, 2012 at 07:16:24PM +0000, ext shane.kearns at accenture.com wrote:
>
> (rc1)-o-o-o-o-o-o-fix-o-o-o-o-o-o-fix
>      \
>       fix(rc2)-fix(v4.8.1)
>
this is no option, because it "loses" the tag from the history.
"traditionally" we have merged back the release branch to the
maintenance branch (and thus to master), which means that we have all
those cherry-picks twice in the history. try to read *that*.
therefore the only clean options are either a) just don't create a
branch or b) if you create a branch, then apply any fixes which are
supposed to be in it *only* to that branch, so it can be cleanly
forward-merged.

> It was pointed out that branches in git are cheap,
>
"branches are cheap" is a bogus argument to start with. it's always the
merging that incurrs the cost (on the human side. technically broken
scms are not worth mentioning).
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development