Thanks for pointing out this issue. A few pointers on your proposal: * On my opinion the hybrid approach is the most practical one. For our case, we compile from the source each release, but it might seem reasonable that patch releases maintain both ABI and API compatibility. * To make sure API and ABI compatibility it would be good to write down the compatibility rules in the documentation (i.e: CONTRIBUTING.md) * Regarding future changes, I agree that there are lots of virtual methods that might not need to be virtual and might be good to re-think the public API for the next major release to improve it. * Also, a note on the fact that we are exporting more symbols than needed. For most cases that's done this way to be able to test some features. So, I'd say both things are closely related and to reduce the exported symbols, as well as the number of virtual methods we might need to work on the testing approach.
BR/ Mario. ________________________________ From: Jacob Barrett <jabarr...@vmware.com> Sent: Monday, February 1, 2021 4:34 PM To: dev@geode.apache.org <dev@geode.apache.org> Subject: Re: [Proposal] Geode Native Library Versioning On Jan 29, 2021, at 3:47 PM, Dan Smith <dasm...@vmware.com<mailto:dasm...@vmware.com>> wrote: I do think at least implementing some automated checking for whatever compatibility we intend to provide is a good idea. I have a branch with a test using Abigail [1]. This branch depends on merging of a CI branch. It was actually through this branch that it was clear we have not been good about preserving any ABI compatibility between releases. I also found that we are exporting more symbols than we should in our library. All these need to be addressed over time. Baby steps I supposed… [1] https://sourceware.org/libabigail/ -Jake
