xserver ABI freeze policy (was: [PATCH] hw/xfree86: Restore API compatibility for cursor loading functions)
aplattner at nvidia.com
Mon Apr 28 07:12:31 PDT 2014
On 04/27/2014 09:37 PM, Keith Packard wrote:
> Aaron Plattner <aplattner at nvidia.com> writes:
>> Doesn't this break the ABI vs. xorg-server-22.214.171.1242? I think just
>> moving the new-vs-ABI17 void-returning fields to the end would fix it
>> since xf86CreateCursorInfoRec() uses calloc() to allocate the
> Yes, it does. I wondered if you wanted me to just bump the ABI number
> again to be able to tell that this has changed. As you know, I prefer to
> have functions placed logically within the structure to make reading the
> definition easier. It's too easy to miss something when functions are
> ordered chronologically...
> I want to treat the temporary mistake of changing the function return
> type as a bug so that existing drivers retain API compatibility with the
> new server version. I'm happy to say that with the current fix, my
> existing drivers 'just work' again.
> If you send in an ABI version bump, I'll merge it in immediately.
Perhaps the point of freezing the ABI early wasn't clear. We have a
relatively long release pipeline, so things like changes to the X SDK
headers have to be checked in fairly early so a driver built against
those headers can go through the QA process. Then, once a driver is
released, distributions want to perform their own testing so that they
can be relatively confident that they can roll a new driver out to their
users without breaking too many people. This lets them roll out a new X
server faster because they have a well-tested NVIDIA driver they can use
Changing the ABI at the last minute, even if you bump the ABI version
number, defeats the purpose of that. In this case, I just added support
for ABI 17 so that driver that in theory will support the upcoming
xserver 1.16 can be released relatively soon. If we bump the ABI to 18
now, then you'll make the changelog entry I added a lie.
This last-minute bumping of the ABI in what is supposed to be a code
freeze happens rather frequently. Since this seems to be the preferred
method of doing things, do you want to go back to the way it used to be,
where the ABI is only really officially frozen once the .0 release comes
out? I can certainly hold off adding official support for new ABIs
until then, but please note that that will delay adoption of the new X
server by distributions significantly due to the reasons I listed above.
More information about the xorg-devel