[Development] Starting preparations for Qt 5.1
Turunen Tuukka
Tuukka.Turunen at digia.com
Mon Mar 18 12:00:57 CET 2013
On 18.3.2013 12.42, "Sean Harmer" <sean.harmer at kdab.com> wrote:
>On Monday 18 March 2013 10:27:45 Shaw Andy wrote:
>> > Making of Qt 5.1 minor release will soon start:
>> >
>> > - Plan is to move 'dev' into 'stable' branch on March 19th.
>> >
>> > - After March 19th any changes that are required to get in for 5.1
>> >
>> > need to be pushed into 'stable' branch. So if your needed changes
>>don't
>> >
>> > make it today,
>> >
>> > please wait after the merge is done and re-target it.
>> >
>> > - I haven't planed to create any branch yet for commits already in
>> > 'stable' and not in 'release'. So speak up if this is needed.
>> >
>> > - If we decide to do 5.0.3, it could be done from the 'release'
>>branch.
>>
>> Considering that people have been developing on stable on the basis
>>that it
>> is in fact 5.0.x, I think we should at least make sure that those
>>changes
>> end up somewhere in case we do a 5.0.3 release for whatever reason.
>>Rather
>> than lose those changes because we merged, could a read only branch be
>> created from the current stable and then merge that into release should
>>a
>> 5.0.3 release happen? So no more work would be done for 5.0.x unless it
>>is
>> decided to make a 5.0.3 release.
>
>I agree. 5.0.3 may never happen but this is good practise and a sensible
>precaution to take in case we do decide to release one.
It is not very likely that someone decides to stay with 5.0.x, so whatever
we do should be such that encourages users to get to 5.1.x, thus we do not
need 5.0.x to overlap with 5.1.x as we do with 4.8.x.
As you know 5.0.2 is in the works to be out soon and will introduce a
great number of fixes over 5.0.1. I hope they are enough to carry us to
5.1.0.
I see three reasons for making 5.0.3:
-> A security issue mandating immediate fix release => that can and should
be done on top of 5.0.2 with a minimal amount of fixes directly in the
release branch
-> A 'brown paper bag' issue in 5.0.2 mandating fix and making or 5.0.3 to
have something usable => that can and should be done in the release branch
with very small amount of changes to 5.0.2
-> Severe problems in getting 5.1 out increasing the need of getting 5.0.3
=> In this situation everyone doing releases is working with 5.1, so even
if there is a need, we can not make 5.0.3 without causing even more
problems to 5.1 (please not that this is a theoretical situation, I do not
expect any problems with 5.1)
Thus I think that it is enough to tag the stable branch before we merge
from dev. In case we ever need to get the situation before, it can be done
easily.
Yours,
Tuukka
More information about the Development
mailing list