On terça-feira, 17 de abril de 2012 15.37.35, marius.storm-ol...@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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
