[Development] Deprecation warnings are enabled

bradley.hughes at nokia.com bradley.hughes at nokia.com
Wed May 2 10:28:38 CEST 2012


On 30 Apr, 2012, at 22:13 , ext Thiago Macieira wrote:
>>> 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.
> 
> This is what answers the "now" part. The changes I'm making, like the QRegExp 
> one and these deprecation settings, are changing the API that we expose to 
> users. As such, I understand that they need to be done, ready and tested by 
> the beta release.

I understand wanting to validate the API that Qt programmers will be using, but enabling this warnings for the people that are working *on* Qt seems like you're targeting the wrong audience. You want the people using Qt to test them. The people working frantically to get Qt working don't need interruptions right now.

> Because of that, the QRegExp change could not be postponed. Hence, even though 
> fixing them might be low-hanging fruit, they are nevertheless necessary.

In the case of QRegExp, I disagree. This caused disruption for no net gain and was completely unnecessary.

>>> 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?
> 
> Again, because having a proper API that we won't change much afterwards is the 
> point of the beta.

But the API inside Qt is constantly changing, and we continue to change. I refer back to my target audience comment from before. Validating the API isn't something that happens inside Qt.

> If we can't have that, then we don't have a beta. We have a second alpha.

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







More information about the Development mailing list