engine.properties

# chDB engine baseline for this Java binding.
#
# Work plan sections 0 and 2: the engine release, its per-platform asset name and the
# SHA-256 of every asset are pinned here. CI must never resolve a "latest" URL.
# Changing engine.version requires a new Maven version and a full four-platform re-test;
# keep this file in sync with <chdb.engine.version> in the root pom.xml.
#
# Checksums are the release asset digests published by GitHub for the tag below
# (gh api repos/chdb-io/chdb-core/releases/tags/v26.7.3 --jq '.assets[].digest').
#
# engine.version is what chdb_version() returns from the shared library, not the tag with
# its 'v' stripped and not the version in the wheel file names. The loader compares the two
# and refuses a mismatch, so this is measured rather than derived: dlopen the macos-arm64
# asset, call chdb_version(), and it returns "26.7.3". All four sources agree on this release
# -- tag, wheel names, tarball header and chdb_version() -- which they did not on the
# previous baseline, where the asset reported "26.7.2-rc.2" while its wheels were named
# 26.7.2. Agreement is the happy case, not the rule; keep measuring it.
#
# v26.7.3 is a STABLE chdb-core release (published 2026-09-10, prerelease=false). That is what
# work plan section 4.3 requires of a V1 GA engine: a binding built on an engine RC is itself
# a preview, so the previous v26.7.2-rc.2 baseline was a release blocker in its own right.
#
# It also carries chdb-core #224, which fixes the signal-handler window reported as chdb-core
# #221 and tracked here as issue #14: scripts/run-signal-window-test.sh measure reports
# hostHandlersAtSigDfl=0 on this engine, against 688/613/724 on v26.7.2-rc.2, and its stress
# mode survives 6 of 6 runs where v26.7.2-rc.2 killed the JVM 8 times out of 8. Re-run both
# on the next baseline: a regression there is invisible to every other test.

engine.version=26.7.3
engine.tag=v26.7.3
engine.repo=chdb-io/chdb-core
engine.asset.base=https://github.com/chdb-io/chdb-core/releases/download/v26.7.3

# platform id -> release asset name
asset.macos-aarch64=macos-arm64-libchdb.tar.gz
asset.macos-x86_64=macos-x86_64-libchdb.tar.gz
asset.linux-x86_64-gnu=linux-x86_64-libchdb.tar.gz
asset.linux-aarch64-gnu=linux-aarch64-libchdb.tar.gz

# platform id -> SHA-256 of the release asset
sha256.macos-aarch64=5640e50dccf711bf3dd5551333d08e43f433edf7bd94b2289f36c2539e627762
sha256.macos-x86_64=af5ded3ed3e84c31af1cd198dcf459f11d2b6aad4f6ddeccc04b8a519b0300fc
sha256.linux-x86_64-gnu=bc33260c32acf78eade2ac41a9115f38e00404651fa42e3bb4c419e4f011c031
sha256.linux-aarch64-gnu=d153adad1ff39b2e3caf0417f09d8bd9edd41939c7c67a3c4978a61e73fb9227

# platform id -> the libchdb file name inside the extracted tarball / the name we ship
libname.macos-aarch64=libchdb.so
libname.macos-x86_64=libchdb.so
libname.linux-x86_64-gnu=libchdb.so
libname.linux-aarch64-gnu=libchdb.so

# platform id -> minimum macOS the shim is built for.
#
# Must not exceed what the engine supports, or the package refuses to load for users in
# between. These are the versions chdb-core's own release wheels declare
# (chdb_core-26.7.3-cp39-abi3-macosx_11_0_arm64.whl and ...-macosx_10_15_x86_64.whl), and
# build-native.sh fails the build if the shim ends up above the engine's.
#
# Re-checked against the v26.7.3 binaries rather than trusting the wheel names:
# `vtool -show-build libchdb.so` reports minos 11.0 for the arm64 asset and 10.15 for the
# x86_64 one, so the two values below still match what the engine will actually load on.
# Both assets were downloaded and read for this, not inferred from the previous baseline.
#
# Left unset, the target follows the build machine's SDK: an unpinned build on a macOS 26
# host produced a shim demanding macOS 26 beside an engine that runs on 11.
#
# The linker clamps upward to the architecture's own minimum, so asking for 10.15 on arm64
# yields 11.0. That is why the two values differ rather than both being 10.15.
deployment.target.macos-aarch64=11.0
deployment.target.macos-x86_64=10.15

# platform id -> the highest glibc the package may require.
#
# Not a target to hit but a ceiling not to exceed: the shim currently lands at 2.25 when built
# in manylinux_2_28, comfortably under. The ceiling is 2.28 because that is the oldest glibc
# still on a supported platform -- RHEL 8 and its rebuilds, maintained to May 2029. Everything
# below it is out of support: RHEL 7 (2.17) ended June 2024 and Amazon Linux 2 (2.26) June
# 2026. Everything above it is already covered.
#
# Unchanged by the v26.7.3 move, checked two ways. Its Linux wheels carry the same
# manylinux2014/manylinux_2_17 tags v26.7.0's and v26.7.2-rc.2's did, and the released engines
# themselves ask for less than that: the highest GLIBC_* symbol version in the x86_64 asset is
# GLIBC_2.4, and in the aarch64 asset GLIBC_2.17. So the engine's own floor did not rise and
# the ceiling still has room.
#
# What this cannot check from a macOS host is the *shim's* floor, which is the thing the
# ceiling actually guards. That is measured in the Linux jobs, where build-native.sh reads it
# off the shim it just built and fails if it exceeds the value below.
#
# Exceeding this means the Linux shim was built outside the manylinux_2_28 container, which is
# how the floor silently became 2.34 once before.
max.glibc.linux-x86_64-gnu=2.28
max.glibc.linux-aarch64-gnu=2.28

# platform id -> the JNI shim file name we build alongside it
jniname.macos-aarch64=libchdb_java_jni.dylib
jniname.macos-x86_64=libchdb_java_jni.dylib
jniname.linux-x86_64-gnu=libchdb_java_jni.so
jniname.linux-aarch64-gnu=libchdb_java_jni.so