I'm not sure this is entirely true. The reason stated for not updating to 1.5.0 in the kernel was related to API/ABI incompatibilities.

The reason stated for not updating to 1.5.0 in the kernel was related to API/ABI incompatibilities.

The reason I'm updating the kernel to a release of zstd that will be called zstd-1.4.10, which is based on zstd-1.4.9 is because:

• The zstd-1.4.9 release was already tested in kernel-space
• zstd-1.5.0 introduces a ~1KB stack space usage regression for higher compression levels
• zstd-1.5.0 introduces heavier usage of SIMD intrinsics, that I need to test in kernel space

I intend to update the kernel to zstd-1.5.1 after my upgrade is merged.

Zstd provides ABI & API compatibility for its stable API (all functions not hidden behind #ifdef ZSTD_STATIC_LINKING_ONLY in the header).

For functions hidden behind ZSTD_STATIC_LINKING_ONLY we don't guarantee API/ABI stability, as its intended for experimental features we aren't sure we will support long term. But so far we've provided it for all symbols except ZBUFF_.* symbols, which we've removed from the library in zstd-1.5.0, and have been emitting deprecation warnings since zstd-1.1.2 released in December 2016. It is also still possible to build zstd-1.5.0 with ZBUFF_.* symbols if we wanted to.

Scratch build: https://cbs.centos.org/koji/taskinfo?taskID=2592593

Built and tagged zstd-1.5.0-2.hs.el8 for -release