The linux wheels build on manylinux2014, whose CentOS 7 base predates every native toolchain need this project has grown. Getting 0.5.0 to build there (#750, #751) required downloading protoc (distro version 2.5.0), installing libclang from an LLVM 7 software collection, and handing bindgen the library path and builtin-header include explicitly because the SCL layout defeats libclang's own resource lookup. The aarch64 step additionally carries CFLAGS_aarch64_unknown_linux_gnu="-D__ARM_ARCH=8" for ring, with a comment saying it can go once the image moves to 2_28.
Moving to manylinux_2_28 (AlmaLinux 8) removes all of that except the pinned protoc download (the 8.x distro protoc is 3.5, still too old): the distro clang-devel is clang 21 and bindgen finds it with no environment handed in, and ring compiles without the CFLAGS workaround. Verified in quay.io/pypa/manylinux_2_28: lance-encoding 11.0.0, librocksdb-sys 0.16.0 and ring 0.17.14 all compile clean.
The cost is the wheel floor moving from glibc 2.17 to 2.28, dropping CentOS 7, Ubuntu 18.04, and Amazon Linux 2, all past end of life. In practice nothing is lost: pyarrow, numpy, and the datafusion python package, the packages hudi wheels run alongside, ship manylinux_2_28 wheels only, so any environment excluded by the new floor already cannot install the surrounding stack.
Targeting 0.6.0: the 0.5.0 release ships from manylinux2014 (#751) so the floor does not change mid-release, and 0.5.0 already raises the Python floor to 3.10, so the two compatibility changes land in separate releases.
The linux wheels build on
manylinux2014, whose CentOS 7 base predates every native toolchain need this project has grown. Getting 0.5.0 to build there (#750, #751) required downloading protoc (distro version 2.5.0), installing libclang from an LLVM 7 software collection, and handing bindgen the library path and builtin-header include explicitly because the SCL layout defeats libclang's own resource lookup. The aarch64 step additionally carriesCFLAGS_aarch64_unknown_linux_gnu="-D__ARM_ARCH=8"for ring, with a comment saying it can go once the image moves to 2_28.Moving to
manylinux_2_28(AlmaLinux 8) removes all of that except the pinned protoc download (the 8.x distro protoc is 3.5, still too old): the distroclang-develis clang 21 and bindgen finds it with no environment handed in, and ring compiles without the CFLAGS workaround. Verified inquay.io/pypa/manylinux_2_28:lance-encoding11.0.0,librocksdb-sys0.16.0 andring0.17.14 all compile clean.The cost is the wheel floor moving from glibc 2.17 to 2.28, dropping CentOS 7, Ubuntu 18.04, and Amazon Linux 2, all past end of life. In practice nothing is lost: pyarrow, numpy, and the datafusion python package, the packages hudi wheels run alongside, ship
manylinux_2_28wheels only, so any environment excluded by the new floor already cannot install the surrounding stack.Targeting 0.6.0: the 0.5.0 release ships from
manylinux2014(#751) so the floor does not change mid-release, and 0.5.0 already raises the Python floor to 3.10, so the two compatibility changes land in separate releases.