[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:

>Hi Lars
>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
pre-announced changes.
>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
>advance :).
>On Sun, Mar 18, 2012 at 8:55 PM,  <lars.knoll at nokia.com> wrote:
>Hi everybody,
>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
>new QUrl.
>* 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
>mailing list
>* 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
>plugins have
>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 mailing list