On 04/27/2014 09:37 PM, Keith Packard wrote:
Aaron Plattner <[email protected]> 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
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
