> From: Keith Packard <[email protected]> > Date: Mon, 28 Apr 2014 15:59:32 -0700 > > Aaron Plattner <[email protected]> writes: > > > 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. > > 1.16 is scheduled to be released at mid-year, we've still got two months > to go. The freeze process for the X server takes half of the development > cycle, and we're now one month into that.
Right, we're not talking about changing the ABI because somebody is trying to sneak in a new feature after feature freeze. We're changing the ABI to fix a mistake made earlier in the release cycle. That seems perfectly acceptable to me. I'd even go as far as saying that making such changes would be acceptable much closer to release time if needed. > I'm not willing to ship 1.16 with the API that was released at the > feature freeze; it has a bug where existing drivers would > build and mostly run, except that cursors would fail in mysterious ways. > > That's clearly not acceptable for the 1.16 release. We either need an > API change that breaks compilation (so that users are forced to fix > them), or a cross-version compatible API. A cross-version compatible API > is obviously preferred as that will allow people to separately migrate > driver packages to the new API as they please. There are many open source drivers out there, and basically only one binary driver. And that binary driver is only provided for a subset of the supported platforms. As such API stability is much more important than ABI stability. But if Aaron/NVIDIA really wants to stick to the current ABI, I'd say they should do the work of fixing and testing all the open source drivers. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
