Repository navigation
Expand file tree
/
Copy pathengine.properties
More file actions
109 lines (102 loc) · 6.24 KB
/
Copy pathengine.properties
File metadata and controls
109 lines (102 loc) · 6.24 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
# 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.11.0-rc.2 --jq '.assets[].digest'), and
# the release's SHA256SUMS asset agrees with them.
#
# 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 linux-x86_64
# asset, call chdb_version(), and it returns "26.11.0-rc.2", which is also the CHDB_VERSION
# in the chdb.h every one of the four tarballs ships. The wheels disagree, as they did on
# v26.7.2-rc.2: they are named 26.11.0, without the qualifier. Agreement is the happy case,
# not the rule; keep measuring it.
#
# v26.11.0-rc.2 is a chdb-core PRE-RELEASE (published 2026-11-05, prerelease=true; not on
# PyPI), pinned to validate the ClickHouse 26.11 baseline ahead of the stable v26.11.1. It is
# v26.11.0-rc.1 plus chdb-core #312, on the same ClickHouse baseline (26.11.1.1). Work plan
# section 4.3: a binding built on an engine RC is itself an RC and cannot be V1 GA, so while
# this is the baseline only -rc.<n> versions may be cut (1.0.0-rc.2 is cut from it; 1.0.0-rc.1
# stays on v26.7.3), and the stable engine has to be re-pinned before 1.0.0. The last stable
# baseline was v26.7.3.
#
# chdb-core #224, the fix for the signal-handler window reported as chdb-core #221 and
# tracked here as issue #14, arrived in v26.7.3: scripts/run-signal-window-test.sh measure
# reported hostHandlersAtSigDfl=0 there, against 688/613/724 on v26.7.2-rc.2, and its stress
# mode survived 6 of 6 runs where v26.7.2-rc.2 killed the JVM 8 times out of 8. Re-run both
# on every new baseline: a regression there is invisible to every other test.
# Re-run on v26.11.0-rc.1, on linux-x86_64: measure 3 reported hostHandlersAtSigDfl=0/0/0
# over ~1.08M samples a run, and stress 6 survived 6 of 6 with 0 killed.
# Re-run on v26.11.0-rc.2, on linux-x86_64: measure 3 reported hostHandlersAtSigDfl=0/0/0
# over ~1.11-1.25M samples a run, and stress 6 survived 6 of 6 with 0 killed.
engine.version=26.11.0-rc.2
engine.tag=v26.11.0-rc.2
engine.repo=chdb-io/chdb-core
engine.asset.base=https://github.com/chdb-io/chdb-core/releases/download/v26.11.0-rc.2
# 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=c9c92100e2b2ff95a5e95055cfce46855da99ee082d21f19ccbb15e0a66bd185
sha256.macos-x86_64=f3aaeabfc79bb43f92b971b5a8eefe59488525ae16145c17bcd6ba028325832a
sha256.linux-x86_64-gnu=f180eb9dfee3536b5017cb01e70369defff19f96ef4c351bf707e80d19ab739a
sha256.linux-aarch64-gnu=065b63064107172317b8d631bfc2ec08e22249695ecc8611def33fee589f26ca
# 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.11.0-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.11.0-rc.2 binaries rather than trusting the wheel names: the
# LC_BUILD_VERSION load command of each asset's libchdb.so (what `vtool -show-build` prints)
# says 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.11.0-rc.2 move, checked two ways. Its Linux wheels carry the same
# manylinux2014/manylinux_2_17 tags every baseline since v26.7.0 has, and the released engines
# themselves ask for less than that: the highest GLIBC_* symbol version in the x86_64 asset is
# still 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