[Development] Commit policies and the Qt 5 alpha
lars.knoll at nokia.com
lars.knoll at nokia.com
Mon Mar 19 11:51:05 CET 2012
On 3/19/12 9:19 AM, "ext Thorbjørn Martsum" <tmartsum at gmail.com> wrote:
>You are the boss :) - and I am not disagreeing that this should happen
>rather sooner then later (it is actually happening very late if the final
>release plan still says june),
>but I however think it would be better (in the future) to announce such
>an api soft freeze a few days before it happens.
The problem with that is that you then get a rush of changes in that
destabilize things. I've seen that happen a couple of times with
>I think some of current codereview pending api_changes would either be in
>Qt by now or abandoned if this had been announced e.g a week ago.
We have a bit of backlog to clean out there, yes.
But api_changes is not master, so BIC changes in that branch are (right
now) not really a concern to me, as they'll land in master in one atomic
>I have a small change like
>https://codereview.qt-project.org/#change,20352 - I know it is not an ML
>(since this it is just something we should try to avoid).
>But I would
>either have preferred avoided making it or made sure got into Qt before
>such a soft api
> soft freeze (where we should try to avoid binary incompatible changes).
I was talking about trying to avoid BC breaks, not that we shouldn't do
them if we have good reasons. One way to deal with BC breakages is
actually to collect a few of them and then submit them together to
minimize disruptions for others.
This is actually what api_changes does, BIC changes can still go in there
whenever it fits, as the merge to master will group them all together.
But api_changes will probably cease to exist after the next merge (ie. in
a week or two from now).
>If anything has been announced and I have missed it - or this actually
>was the idea with the feature freeze - I would like to apologize in
>On Sun, Mar 18, 2012 at 8:55 PM, <lars.knoll at nokia.com> wrote:
>there are quite a few people meeting up in Oslo this week, and we'll try
>to finish up the Qt 5 alpha there. For this reason I'd like everybody to
>restrain themselves in what they submit to the master branch. The main
>focus needs to be to get the alpha, so please focus on staging only
>commits that help us get the alpha out.
>At the same time, I'd like to announce that we need to tighten our policy
>regarding changes to Qt 5 a bit more. This is required for us to really
>focus on stabilizing Qt 5, and bringing us onto the right path towards a
>Here are the new rules for essential modules:
>* From now on no more changes that are source incompatible with Qt 4.8.
> 1-2 exceptions are still waiting in the API changes branch and
>* No more source incompatible changes to features/API that are new in Qt
>5, unless approved by the module's maintainer after a discussion on the
>* Try to avoid binary incompatible changes, as they slow down development.
>* The only changes that should still go in are:
> - Regressions against Qt 4.x (this implies that the platform
>some more freedom)
> - Major bugs for functionality that has been there in 4.x
> - Bug fixes to new functionality
> - Performance improvements
> - Improvements to memory consumption
>Qt Addons are encouraged to follow the same rules if they want to have a
>5.0 release at around the same time as Qt 5.0.
>Development mailing list
>Development at qt-project.org
More information about the Development