Hi Faidon, Good news on the ABI question we paused on: it's resolved upstream, and along the lines you suggested.
1) Symbol versioning, not a SONAME bump Upstream adopted symbol versioning. The five "limit" C functions now export a default @@WASMEDGE_0.17 plus a @WASMEDGE_0.16 compat shim, driven by an ELF version script (lib/api/libwasmedge.lds) and .symver aliases in lib/api/wasmedge_compat.cpp: PR: https://github.com/WasmEdge/WasmEdge/pull/4951 (merged) Issue: https://github.com/WasmEdge/WasmEdge/issues/4933 (closed) So the SONAME stays libwasmedge.so.0 and no package rename is needed, while a previously-compiled 0.16 consumer keeps the old ABI. 2) Verified that crun stays safe without a rebuild The subtle part is whether an already-compiled 0.16 binary (which carries an *unversioned* reference, like Debian's crun) binds to the @WASMEDGE_0.16 shim rather than the new @@0.17 default. I tested this empirically: a consumer compiled against Debian's real libwasmedge-dev 0.16.1 headers, run against the new library, round-trips the Limit struct correctly. So partial upgrades are safe; crun does not need a rebuild for correctness (though one is still fine to do). 3) Test suite on the released tarball I ran upstream's test suite (ctest) against the 0.17.1-rc.2 tag, built with the package's own build-deps (LLVM on), in a sid container: ctest: 100% tests passed, 0 tests failed out of 27 (includes the AOT/LLVM tests, e.g. wasmedgeAPIAOTCoreTests; debian:sid, arch arm64) This is arm64, so it's supporting evidence, not the authoritative run — the amd64 run is still yours. Full ctest output is attached (testsuite-rc2-arm64.log). On the integration path, I'd like your preference: (a) Wait for the upcoming 0.17.1 release, which carries the symbol versioning natively, and package that as 0.17.1-1 (no debian/patch needed). 0.17.1 is at rc.2 as of 2026-06-29, so a final tag looks close. (b) Or, if you'd rather not wait, I can package 0.17.0-1 now and carry PR #4951 as a debian/patch in the interim. I lean towards (a) for a cleaner result, but I'm happy to do (b) if you prefer to move sooner. Either way I'll refresh the packaging branch and patch series to match the choice. On Debusine: thanks again for the pointer, but it looks like external login is currently limited to DDs and DMs, so I can't drive it myself as an upstream contributor. I'll rely on your amd64 test run for the authoritative result, as you offered. Thanks again for the guidance on this. Vincent WasmEdge upstream / Second State
