Re-pin the engine baseline to the stable v26.7.3

Work plan §4.3 forbids a V1 GA built on an engine pre-release, so the
v26.7.2-rc.2 baseline was itself a release blocker. v26.7.3 is a stable
chdb-core release (prerelease=false, published 2026-09-10), which clears
it. Maven version follows §4.3's engine-aligned rule: an RC-to-stable move
is a new engine, so the binding revision resets and the version is
26.7.3.1-SNAPSHOT rather than 26.7.2-rc.2.2.

Measured rather than assumed, on the release library and not on an export
list or a wheel name:

  chdb_version()                          "26.7.3"
  chdb.h in the release tarball           26.7.3
  programs/local/chdb.h at the git tag    26.7.2   <-- stale, again

That last row is why chdb-jni/include/chdb.h is copied out of the tarball,
and findings §2's table gains a third column for it: the in-tree constant
did not move at all between v26.7.2-rc.2 and v26.7.3, so a header vendored
from the tag would have declared an engine version the loader refuses.

All four asset SHA-256s were checked against the published digests and then
against the bytes -- every platform's tarball was downloaded and passed
fetch-libchdb.sh's checksum gate, not just the arm64 one that gets built
here. The macOS deployment targets and the glibc ceiling were re-derived
rather than carried over: vtool reports minos 11.0 and 10.15 on the two
macOS assets, and the Linux assets ask for at most GLIBC_2.4 (x86_64) and
GLIBC_2.17 (aarch64), so the 2.28 ceiling still has room.

What the re-pin was for, and the reason it is worth more than a version
bump: v26.7.3 carries chdb-core #224, the fix for the signal-handler window
filed as chdb-core #221 and tracked here as issue #14.

  scripts/run-signal-window-test.sh measure 3
    hostHandlersAtSigDfl = 0 / 0 / 0   over 334488, 331398, 334164 samples
    v26.7.2-rc.2 was      688 / 613 / 724

  scripts/run-signal-window-test.sh stress 6
    6 of 6 survived, 0 killed
    v26.7.2-rc.2 killed the JVM 8 times in 8

Findings §1 and §1a are both resolved, not just the concurrency half.
chDB no longer resets a handler it did not install, so the shim's
SignalGuard has nothing left to repair: SignalHandlerIT reports the set of
signals chDB reset and the shim restored as empty on v26.7.3, where on
v26.7.2-rc.2 it reported SIGSEGV, SIGILL, SIGBUS, SIGFPE and SIGTSTP. The
guard stays regardless -- it is what keeps the driver correct against an
older libchdb, and an empty report only means something because something
is still watching.

The licence inventory was regenerated from the binary being shipped, per
docs/publishing.md §5, by querying system.licenses through the engine
itself. It came out byte-identical to both previous inventories -- 968
components, same licence strings, same SHA-256 as v26.7.0's and
v26.7.2-rc.2's -- and the copyleft set is still exactly the known twelve,
six LGPL and six MPL-2.0, with no thirteenth. So the redistribution
position did not move. That is checked rather than assumed: the file is
keyed by engine version precisely so the next bump can differ.

Prose attributed to a measurement on v26.7.2-rc.2 was left attributed to it
rather than relabelled 26.7.3, which would claim a measurement that was not
taken. What changed are the claims that rc.2 *is* the baseline, and the
facts this release actually re-measured. Twenty-one files still name rc.2,
all of them recording when a symbol arrived or what was observed then.

Verified on macos-aarch64 only: 194 unit and 173 integration tests green on
JDK 11, 21 and 26; the C++ harness's 199 checks under ASan and UBSan;
build-native.sh's link and deployment-target gates; the platform JAR's
manifest, licences and SBOM, all derived from 26.7.3; loading from the
packaged JAR; and scripts/verify-consumer.sh. linux-x86_64, linux-aarch64
and macos-x86_64 cannot be tested from this host and are unverified until
CI runs -- which §4.3 requires for an engine change.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: ShawnChen-Sirius

.github/workflows/build.yml

@@ -355,7 +355,7 @@ jobs:
               ldd '"$LIBS"'/libchdb_java_jni.so
 
               echo
-              java -Xmx512m                 -Dchdb.library.path='"$LIBS"'                 -Dchdb.it.engine.version=26.7.2-rc.2                 -cp "'"$PWD"'/chdb-jdbc/target/classes:'"$PWD"'/chdb-integration-tests/target/test-classes:'"$(cat target/it-cp.txt)"'"                 org.junit.platform.console.ConsoleLauncher execute                 --select-package=org.chdb.it                 --include-classname=".*IT"                 --details=summary                 --disable-banner                 --fail-if-no-tests
+              java -Xmx512m                 -Dchdb.library.path='"$LIBS"'                 -Dchdb.it.engine.version=26.7.3                 -cp "'"$PWD"'/chdb-jdbc/target/classes:'"$PWD"'/chdb-integration-tests/target/test-classes:'"$(cat target/it-cp.txt)"'"                 org.junit.platform.console.ConsoleLauncher execute                 --select-package=org.chdb.it                 --include-classname=".*IT"                 --details=summary                 --disable-banner                 --fail-if-no-tests
             '
 
       - name: A query over the memory limit returns an exception, not an OOM kill

README.md

@@ -39,11 +39,11 @@ and is loaded from a real packaged JAR, in CI:
   engine does. Each package records the figure it was built against in its
   `manifest.properties`, and CI runs the whole test suite on AlmaLinux 8 to demonstrate the
   floor rather than infer it from symbol versions.
-- **Engine:** chDB Core **26.7.2-rc.2**, pinned. The C ABI is version-locked, so the driver
+- **Engine:** chDB Core **26.7.3**, pinned. The C ABI is version-locked, so the driver
   refuses to run against a different engine build rather than risking a struct-layout mismatch.
-  That release is a chdb-core *pre-release*, pinned because it is the first to export
-  `chdb_shutdown()`; a binding on an engine RC is itself a preview and is not the V1 GA
-  ([work plan §4.3](CHDB_JAVA_V1_WORK_PLAN.md)).
+  That release is a stable chdb-core release, which is what [work plan
+  §4.3](CHDB_JAVA_V1_WORK_PLAN.md) requires of a V1 GA engine: the previous baseline,
+  `26.7.2-rc.2`, was a pre-release and made every binding built on it a preview.
 - **Not supported:** Windows, musl (Alpine), 32-bit, GraalVM Native Image, Android. See
   [work plan §2.3](CHDB_JAVA_V1_WORK_PLAN.md).
 
@@ -58,7 +58,7 @@ on. The native package pulls in the driver, so declaring it alone is enough.
 <dependency>
   <groupId>org.chdb</groupId>
   <artifactId>chdb-native-linux-x86_64-gnu</artifactId>
-  <version>26.7.2-rc.2.1</version>
+  <version>26.7.3.1</version>
 </dependency>
 ```
 
@@ -71,7 +71,7 @@ architecture — declare the driver plus each native package you need:
     <dependency>
       <groupId>org.chdb</groupId>
       <artifactId>chdb-bom</artifactId>
-      <version>26.7.2-rc.2.1</version>
+      <version>26.7.3.1</version>
       <type>pom</type>
       <scope>import</scope>
     </dependency>
@@ -102,10 +102,11 @@ unpacked. There is no all-platforms package, on purpose: it would be the sum of
 
 ### Versioning
 
-`<engine version>.<binding revision>`, so `26.7.2-rc.2.1` is the first Java release built
-against engine 26.7.2-rc.2 — the engine version is carried through verbatim, `rc` qualifier
-included. A new engine always means a new version, and moving from one RC to another, or from
-an RC to the stable release, counts as a new engine and resets the binding revision to `1`.
+`<engine version>.<binding revision>`, so `26.7.3.1` is the first Java release built
+against engine 26.7.3 — the engine version is carried through verbatim, `rc` qualifier
+included when there is one. A new engine always means a new version, and moving from one RC to
+another, or from an RC to a stable release, counts as a new engine and resets the binding
+revision to `1`: that is why the move off `26.7.2-rc.2.1` is `26.7.3.1` and not `26.7.2-rc.2.2`.
 This is not SemVer; see [work plan §4.3](CHDB_JAVA_V1_WORK_PLAN.md).
 
 ## Connecting

chdb-bom/pom.xml

@@ -7,7 +7,7 @@
   <parent>
     <groupId>org.chdb</groupId>
     <artifactId>chdb-java-parent</artifactId>
-    <version>26.7.2-rc.2.1-SNAPSHOT</version>
+    <version>26.7.3.1-SNAPSHOT</version>
   </parent>
 
   <artifactId>chdb-bom</artifactId>

chdb-examples/pom.xml

@@ -7,7 +7,7 @@
   <parent>
     <groupId>org.chdb</groupId>
     <artifactId>chdb-java-parent</artifactId>
-    <version>26.7.2-rc.2.1-SNAPSHOT</version>
+    <version>26.7.3.1-SNAPSHOT</version>
   </parent>
 
   <artifactId>chdb-examples</artifactId>

chdb-integration-tests/pom.xml

@@ -7,7 +7,7 @@
   <parent>
     <groupId>org.chdb</groupId>
     <artifactId>chdb-java-parent</artifactId>
-    <version>26.7.2-rc.2.1-SNAPSHOT</version>
+    <version>26.7.3.1-SNAPSHOT</version>
   </parent>
 
   <artifactId>chdb-integration-tests</artifactId>

chdb-integration-tests/src/test/java/org/chdb/it/NonStreamableResultsIT.java

@@ -412,7 +412,7 @@ void tableShorthandIsNotSupportedByTheEngine() throws Exception {
      * pinned -- which matters, because the answer for the dangerous statement below does.
      *
      * <p>{@code WITH q AS (...) INSERT INTO t SELECT ...} parses, writes, and has a leading
-     * keyword the scan calls a result set. On the v26.7.2-rc.2 baseline {@code
+     * keyword the scan calls a result set. On v26.7.2-rc.2 {@code
      * chdb_classify_query_n} reports it MUTATING, so it is routed to {@code chdb_query_n} and
      * simply works. Without the classifier the keyword scan sends it to the streaming door,
      * which refuses it, and it is reported rather than retried -- which is the whole reason

chdb-integration-tests/src/test/java/org/chdb/it/ProcessLifecycleIT.java

@@ -146,7 +146,7 @@ private static final class ForkResult {
      * exiting with a Connection open is fine, and closing the Connection while a stream is open
      * is fine, because that closes the stream. Only an open stream at exit does it.
      *
-     * <p>Still true on engine 26.7.2-rc.2, which is the baseline that added {@code
+     * <p>Still true on engine 26.7.2-rc.2, the release that added {@code
      * chdb_shutdown()}: that call declines to do anything while a connection is open, so it
      * does not replace the hook's drain. See {@link #chdbShutdownStopsTheEngine()}.
      */

chdb-integration-tests/src/test/java/org/chdb/it/SignalHandlerIT.java

@@ -271,7 +271,7 @@ private static Map<String, String> parseDispositions(String report) {
     @DisplayName("the disposition report covers every signal chDB touches")
     void reportCoversUpstreamsSignalList() {
         String report = ChdbNative.signalDispositions();
-        // chdb_reset_signal_handlers()'s own list, as of engine 26.7.2-rc.2.
+        // chdb_reset_signal_handlers()'s own list, as of engine 26.7.3.
         for (String signal :
                 new String[] {
                     "SIGABRT", "SIGSEGV", "SIGILL", "SIGBUS", "SIGSYS", "SIGFPE", "SIGTSTP", "SIGTRAP"

chdb-jdbc/pom.xml

@@ -7,7 +7,7 @@
   <parent>
     <groupId>org.chdb</groupId>
     <artifactId>chdb-java-parent</artifactId>
-    <version>26.7.2-rc.2.1-SNAPSHOT</version>
+    <version>26.7.3.1-SNAPSHOT</version>
   </parent>
 
   <artifactId>chdb-jdbc</artifactId>

chdb-jdbc/src/main/java/org/chdb/internal/ChdbNative.java

@@ -53,7 +53,7 @@ private ChdbNative() {
     /** ABI version the loaded shim was built with. */
     public static native int jniAbiVersion();
 
-    /** {@code chdb_version()} of the loaded libchdb, e.g. {@code "26.7.2-rc.2"}. */
+    /** {@code chdb_version()} of the loaded libchdb, e.g. {@code "26.7.3"}. */
     public static native String engineVersion();
 
     /** Build provenance of the shim: git commit, compiler, engine headers it compiled against. */
@@ -138,7 +138,7 @@ public static native long query(
      * {@code chdb_classify_query_n}. Decides whether a statement has a result set to stream
      * without executing it, using the engine's own parser.
      *
-     * <p>Optional symbol: it landed in chdb-core v26.7.2-rc.2, which is the pinned baseline,
+     * <p>Optional symbol: it landed in chdb-core v26.7.2-rc.2, so the pinned v26.7.3 baseline has it,
      * so it is resolved by {@code dlsym} rather than linked. It is present on the baseline;
      * the null path is what an older engine gets, and means the caller must fall back to
      * {@code StatementShape}'s own analysis.
@@ -266,7 +266,7 @@ public static native long streamOpenMaterialized(
      * every result destroyed first, and the engine cannot be used again in this process.
      *
      * <p>Optional symbol, like {@link #classifyQuery(long, byte[])}: it landed in chdb-core
-     * v26.7.2-rc.2, which is the pinned baseline, so it is resolved by {@code dlsym} rather
+     * v26.7.2-rc.2, so the pinned v26.7.3 baseline has it, and it is resolved by {@code dlsym} rather
      * than linked. Not having it is not a failure -- the threads it would join are reaped by
      * process exit either way.
      *