xserver ABI freeze policy (was: [PATCH] hw/xfree86: Restore API compatibility for cursor loading functions)

[Aaron Plattner]

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-1.15.99.902?  I think just
>> moving the new-vs-ABI17 void-returning fields to the end would fix it
>> since xf86CreateCursorInfoRec() uses calloc() to allocate the
>> structure.
>
> 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 
with it.

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.

Sincerely,
Aaron