Skip to content
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

Open
jorisvandenbossche opened this issue May 17, 2024 · 1 comment
Open

[C++][Docs] Document our ABI stability policy #41707

jorisvandenbossche opened this issue May 17, 2024 · 1 comment

Comments

@jorisvandenbossche
Copy link
Member

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.

@vyasr
Copy link
Contributor

vyasr commented May 21, 2024

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

  • SOVERSION=${MAJOR}${MINOR} (so version 16.1.0 produces libarrow.so.1601, while version 16.0.1 produces libarrow.so.1600)
  • Patch versions are promised to be ABI-compatible (but this is not explicitly verified in any way)
  • Minor versions are not promised to be ABI-compatible
  • Packaging metadata (for conda, haven't looked at others) claims that the packages are compatible between minor versions, so the runtime library is allowed to float across minor versions within the same major family.

Conservative solution

  • SOVERSION=${MAJOR}${MINOR}${PATCH} (so version 16.1.0 produces libarrow.so.160100, while version 16.0.1 produces libarrow.so.160001)
  • Assumes a completely unstable ABI
  • Might be the most strictly accurate claim at the moment
  • Would be quite painful for consumers

Compromise solution

  • Same as the status quo, but packaging is updated to reflect the real ABI guarantees rather than the current misaligned state where packages promise wider ABI-compatibility than the compiled libraries in the package.

Desired state

  • SOVERSION=${MAJOR} (so version 16.1.0 and version 16.0.1 produce libarrow.so.16)
  • Both minor and patch versions are promised to be ABI-compatible
  • This may not be possible for arrow right now.

Summary

If 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.

robomics added a commit to paulsengroup/hictk that referenced this issue Oct 17, 2024
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).
robomics added a commit to paulsengroup/hictk that referenced this issue Oct 17, 2024
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).
robomics added a commit to paulsengroup/hictk that referenced this issue Oct 17, 2024
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).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants