-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[C++][Docs] Document our ABI stability policy #41707
Comments
This will be review for most people discussing here, but just wanted to summarize explicitly to make sure we're clear and all on the same page: Status quo
Conservative solution
Compromise solution
Desired state
SummaryIf minor or patch releases can break ABI, then the SOVERSION must reflect that so that libraries built against libarrow have the appropriate requirements baked into the executable (e.g. DT_NEEDED entries in ELF files). Downstream of the library, packaging metadata (in particular, conda metadata as is being discussed in conda-forge/arrow-cpp-feedstock#1409) must account for this by setting runtime dependencies of dependents of libarrow to account for the right version of libarrow at runtime. Making a decision on #41707 (i.e. clarifying the intended stability promises) is the first thing to be done, then we can work on updating packaging files. |
This is mostly useful for hickpy, where linking to Arrow::arrow_shared causes linking to a specific version of Arrow (which depends on the specific version of Pyarrow that was installed when building hictkpy wheels). This is not desirable, because it forces us to pin the version of pyarrow required by hictkpy (which could easily result in unresolvable environments). Here we assume that libarrow_python.so links to some version of libarrow.so, which when loaded brings in all symbols required by hictk and hictkpy. It should be noted that Arrow has very few guarantees when it comes to ABI stability (see apache/arrow#41707). This means that hictkpy needs to test all possible combinations of pyarrow/arrow versions on all supported platforms and architectures to make sure there are no ABI changes (at least to the parts that hictk and hictkpy depends on).
This is mostly useful for hickpy, where linking to Arrow::arrow_shared causes linking to a specific version of Arrow (which depends on the specific version of Pyarrow that was installed when building hictkpy wheels). This is not desirable, because it forces us to pin the version of pyarrow required by hictkpy (which could easily result in unresolvable environments). Here we assume that libarrow_python.so links to some version of libarrow.so, which when loaded brings in all symbols required by hictk and hictkpy. It should be noted that Arrow has very few guarantees when it comes to ABI stability (see apache/arrow#41707). This means that hictkpy needs to test all possible combinations of pyarrow/arrow versions on all supported platforms and architectures to make sure there are no ABI changes (at least to the parts that hictk and hictkpy depends on).
This is mostly useful for hickpy, where linking to Arrow::arrow_shared causes linking to a specific version of Arrow (which depends on the specific version of Pyarrow that was installed when building hictkpy wheels). This is not desirable, because it forces us to pin the version of pyarrow required by hictkpy (which could easily result in unresolvable environments). Here we assume that libarrow_python.so links to some version of libarrow.so, which when loaded brings in all symbols required by hictk and hictkpy. It should be noted that Arrow has very few guarantees when it comes to ABI stability (see apache/arrow#41707). This means that hictkpy needs to test all possible combinations of pyarrow/arrow versions on all supported platforms and architectures to make sure there are no ABI changes (at least to the parts that hictk and hictkpy depend on).
With the 16.1.0 release, there have been a few issues related to whether this minor / feature release is expected to be ABI stable or expected to have bumped the so version.:
Our release scripts do bump the so version for minor releases, as has been discussed and implemented around the time of the first 1.0.0 release (#4801, mailing list thread).
However, we don't document this policy anywhere AFAIK (and there was clearly also confusion about this among the committers as well). We should document this in the C++ docs somewhere, that the so version is bumped for every major and minor version, and thus consequently that bug-fix releases are expected to be ABI stable.
The text was updated successfully, but these errors were encountered: