[Development] important: upcoming rename of _qpa.h to _p.h

[Thiago Macieira]

On terça-feira, 17 de abril de 2012 15.37.35, marius.storm-olsen at nokia.com 
wrote:
> Yes, it does.
> And for the case of QPA, we have said that we don't want to promise BC, but
> we haven't said that we will go around breaking SC for every patch release.
> (And we shouldn't, since SC breakage uses quite a bit of resources on all
> parties, so avoid them if you can.)

There was no SC promise either. We shouldn't go breaking it completely in 5.1 
or later, but I also see no reason why we couldn't do it if there were the 
need. Also, SC but not BIC changes are very limited -- such as adding non-pure 
virtual functions (which we can do) and adding members to classes (which we 
won't do). Renaming functions or classes or removing them also break BC.

Suppose we detect that the entire keyboard interface is broken and needs an 
overhaul, removing a method. Plugins will need to adapt, period.

> Like some others, I would prefer it to remain in non-private headers, while
> mark the QPA API with non-BC promise. IMO, in Qt 5.1 we should be able to
> promise BC on the QPA APIs too.

I don't like the new category of headers -- it sets a precedent. What's more, 
when we *do* offer SC and BC, I see no reason to have "_qpa" either. It's API 
anyway.

As for whether we can promise source and/or binary compatibility in 5.1, time 
will tell. I hope we can do it, I won't shed a tear if we can't.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120417/985afe19/attachment.sig>