On 3/19/12 9:19 AM, "ext Thorbjørn Martsum" <tmart...@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 merge. > >I have a small change like >https://codereview.qt-project.org/#change,20352 - I know it is not an ML >issue >(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). Cheers, Lars > >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 :). > >Regards >Thorbjørn > >On Sun, Mar 18, 2012 at 8:55 PM, <lars.kn...@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 >release. > >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 >Thiago's >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. > >Cheers, >Lars > >_______________________________________________ >Development mailing list >Development@qt-project.org >http://lists.qt-project.org/mailman/listinfo/development > > > > _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
