[Development] Qt Commercial 4.7.5 is out - how shall we contribute is the best?

[lars.knoll at nokia.com]

On 1/19/12 9:58 PM, "ext Thiago Macieira" <thiago.macieira at intel.com>
wrote:

>On Thursday, 19 de January de 2012 16.49.20, Thiago Macieira wrote:
>> So Digia is operating under special conditions right now, due to the
>>lack
>> of  Qt4 in Gerrit. Once it stabilises, I'd rather not see Digia release
>>a
>> commercial version with a version number that the official Qt doesn't
>>have
>> yet.
>> 
>> That might imply they need a second version number. E.g.:
>> 
>>         Qt Commercial 4.7.5 update 1
>> 
>> which indicates it's the Qt Commercial vendor branch, based on the
>>official
>> Qt  4.7.5, but it's an update to something previously released.
>
>By the way, considering what Ossi said in the other email ("4.7 is closed
>as 
>far as the qt project is concerned [...] [because] fixes are not being
>applied 
>to 4.7 first"), the Qt project needs to make a decision:
>
>- reopen the 4.7 branch and work on it, everyone, when a fix from someone
>(like 
>Digia) turns up
>- tell Digia to stop increasing the version number
>- or turn over the maintenance of the 4.7 branch to Digia, including the
>ability to make releases
>
>My personal preference, seeing how busy everyone is with 5.0 alone, not
>to 
>mention 4.8, is the third option. Turning over maintenance does not mean
>"anything goes", but it means Digia engineers and the rest of the
>community 
>work on the 4.7 branch inside the Qt project. Commits should still be
>reviewed 
>and a Qt project release should still happen. I'm sure there are Linux
>distribution packagers who can help in the release testing for their own
>maintenance updates.
>
>I propose we nominate a release maintainer/manager, who is responsible
>for 
>setting the priorities for that release.

+1 from me.

Option 3 is certainly the best option. As we see Digia still has an
interest in Qt 4.7, but I haven't seen something coming from other sides,
so Digia finding a release manager and maintainer for the branch and then
working inside qt-project.org on it is probably the best solution.

The same might (or might not) apply to 4.8 once we are a bit further with
Qt 5.0.

Cheers,
Lars