[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