Building CI that detects ABI breakage is not hard. There is a closed PR in the arrow repo from me that does exactly this using abi-complicance-checker.
I understand that we will not be able to provide ABI stability on all Arrow subprojects but having it for a core would be really great. This would allow easy upgrading of adaptors that connect to Arrow but don't actually work with the resulting structures (this can be database connectors and file format implementations). Uwe On Sun, Jul 28, 2019, at 10:43 AM, Antoine Pitrou wrote: > > Le 28/07/2019 à 01:49, Wes McKinney a écrit : > > On Sat, Jul 27, 2019 at 4:38 PM Uwe L. Korn <uw...@xhochy.com> wrote: > >> > >> The PIMPL is a thing I would trade a bit of performance as it brings ABI > >> stability. This is something that will help us making Arrow usage in > >> thirdparty code much simpler. > >> > > > > I question whether ABI stability (at the level of the shared library > > ABI version) will ever be practical in this project. In the case of > > NumPy, there are very few C data structures that could actually > > change. In this library we have a great deal more data structures, I > > would guess 100s of distinct objects taking into account each C++ > > class in the library. It's one thing to be API forward compatible from > > major version to major version (with warnings to allow for graceful > > deprecations) but such forward compatibility strategies are not so > > readily available when talking about the composition of C++ classes > > (considering that virtual function tables are part of the ABI). > > > > In any case, as a result of this, I'm not comfortable basing technical > > decisions on the basis of ABI stability considerations. > > We could at some point define a "stable ABI subset" (for example the > core classes Array, ArrayData, etc.). But I'm not sure whether that > would be sufficient for users. > > Also in any case it would need someone to maintain the regular toolkit > and continuous integration hooks to prevent ABI breakage. Otherwise > it's pointless promising something that we can't efficiently monitor. > > Regards > > Antoine. >
