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

[Turunen Tuukka]

Hi All,

Although late for 4.8.1 this is a good discussion to have.

I think the key question that needs to be answered is: Do we aim to have a
model where it is typically ok to take always the latest that exists in
the repository?

If the answer is yes, agreeing not to branch will support the goal.
Drawback is the fact that putting a single fix of top of otherwise working
set will not be feasible. For a patch release it should not be a
significant drawback. And as all things that go in are bug fixes anyway it
should always be ok to have a few more.

Certainly for the minor releases we need to have a branch in order not to
hurt development of new things while getting into release maturity. But
for patch releases it should be feasible to keep release maturity at any
time.

Yours,

--
Tuukka Turunen
Director, Qt Commercial R&D
Digia Plc
Piippukatu 11, 40100 Jyväskylä, Finland
 
Visit us at: www.digia.com or qt.digia.com
 






On 12.3.2012 19.45, "shane.kearns at accenture.com"
<shane.kearns at accenture.com> wrote:

>> 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.
>>
>
>The full picture including the merge back would look like:
>
> (rc1)-o-o-o-o-o-o-fix-o-o-o-o-o-o-fix-o-o-o-M
>     \                                      /
>      fix(rc2)-fix(v4.8.1)-----------------.
>
>The tag has to be on the branch (if there is a branch), otherwise "git
>checkout v4.8.1" doesn't give the same thing as the release tarball.
>Tools that show the history including branches (e.g. gitk) would give a
>picture like what's above, "git log" will show the cherry picks twice in
>the history.
>The history is unreadable for v4.8.0 because of the 7 parallel staging
>branches, but displaying two parallel branches (4.8 and 4.8.1) should be
>sane and readable.
>I believe that "git log v4.8.1.." includes the commits which came in with
>the merge (anything on 4.8 but not on 4.8.1 branch)
>
>________________________________
>Subject to local law, communications with Accenture and its affiliates
>including telephone calls and emails (including content), may be
>monitored by our systems for the purposes of security and the assessment
>of internal compliance with Accenture policy.
>__________________________________________________________________________
>____________
>
>www.accenture.com
>
>_______________________________________________
>Development mailing list
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development