[Development] Changing Qt's Binary Compatibility policy

Allan Sandfeld Jensen kde at carewolf.com
Fri May 31 10:21:24 CEST 2024


On Thursday 30 May 2024 15:56:26 CEST Volker Hilsheimer via Development wrote:
> My larger concern is that for patch releases, we have no processes to avoid
> that we end up adding poor APIs. We don’t do a header review, and we don’t
> have a whatsnew documentation file. The changelog should be enough for the
> kinds of things we are presumably talking about here. But agreeing to this
> will give ourselves the freedom to add new symbols within a patch cycle, so
> we should perhaps narrow this down a bit.
 
> - must fix a P1 bug
> - add symbols required to support new platforms (e.g. new
> QOperatingSystemVersion constants) or otherwise realities out of our
> control (e.g. new locale enum values - not a symbol anyway)
> - doesn’t
> touch any template code, because otherwise we *must* have a header review
> ;) 
> 
We could carve out an exception for new symbols already approved (and 
released) for a newer version of Qt in case it is needed in a patch release. 

One tricky point which is already causing issues sometimes on minor version 
updates is adding new enum values. Code that assumes it knows all possible 
values given to it by Qt, can break if a new value is issued from Qt code. But 
since such code could already break with a minor update, we could take the 
stance that it is also allowed to break with a patch update. 

Best regards
Allan




More information about the Development mailing list