[Development] Deprecation warnings are enabled

bradley.hughes at nokia.com bradley.hughes at nokia.com
Mon Apr 30 21:00:31 CEST 2012


On Apr 30, 2012, at 8:43 PM, ext Thiago Macieira wrote:

> On segunda-feira, 30 de abril de 2012 17.57.46, bradley.hughes at nokia.com 
> wrote:
>> When faced with two options, 1) fix deprecated warnings or 2) continue work
>> to restore Qt 4 behavior in the platform plugins, I'm going to say we
>> should be doing 2) and not do 1) at all (since there will be disruptions
>> and distractions because of it).
> 
> Of course. It doesn't have to be you. I'm hoping that someone will, though.
> 
> Fixing deprecation warnings is usually a task that many new-comer contributors 
> can do and would be a great way for them to gain experience in developing Qt.

But you're missing my point. I don't think anyone should be doing them. I don't think now is the time to have a lot of "low-hanging fruit" changes being pushed into to all the modules.

>>> I'm acting on the belief that this is a beta-blocker task. If it is and
>>> you
>>> need more time, then we may have to delay the beta too. Or, I am mistaken
>>> and it is not a beta-blocker.
>> 
>> I've always been under the impression that the desktop platform plugins
>> won't block any release. The state they are in at release time is the state
>> they are in… we will be constantly fixing and implementing both up to and
>> and well beyond the 5.0 release. Postponing isn't feasible because it's
>> impossible to say how much time is left.
> 
> Indeed. Though I expect that we will only release if we have something we can 
> be proud of. A brown-paper bag release that just inflames even more the 
> community will do us no good. That's a subjective determination though.

The amount of changes going into Qt 5 is certainly enough to be proud of, but there will be feature and behavior regressions on the desktop platforms, there's no avoiding that.  We want to close that gap as much as possible, but disruptions will slow us down.

> Still, I meant my own task: since these are API-level considerations, I was 
> and still am under the impression that they are needed by beta time.

I'm not sure what you mean by this.

>> Summing up, this is what I'm afraid of: we're going to end up wasting a lot
>> of time fixing things that are in the way, not because they are important
>> right now (note that I'm not saying they are unimportant altogether, just
>> that there other things trump them).
> 
> Though it has just occurred to me that we have a way to accomplish both of our 
> objectives:
> 
> it's possible to make the Qt API clean for users by the beta release, yet not 
> affect much of our internals. All I need to do is change the default in 
> qglobal.h, like I've done, but ensure that all of Qt, including examples, is 
> still compiled with 4.9 API.

This option might work, but again I have to ask: why do anything at all? Doing nothing and keeping things as-is is an option as well, is it not? Why add entropy to the system?

--
Bradley T. Hughes
bradley.hughes at nokia.com




More information about the Development mailing list