docs: sweep versions to the 0.23.0 train - #334
Merged
Merged
Conversation
core/repl 0.23.0 · extensions 0.3.2 · arrow 0.3.3 · jdbc 0.3.3.
Per-occurrence triage, not a blanket replace. Every version WRITTEN here was
confirmed to return 200 on JFrog first (jdbc + adbc drivers es6/7/8/9 0.3.3,
java-client 0.23.0, arrow-extensions 0.3.3, community-extensions 0.3.2) — the
check that previously caught a doc installing a version that never shipped.
Deliberately NOT bumped:
- `joins.md` "since arrow-extensions 0.2.5 (REPL bundle 0.20.4, driver 0.2.5)"
— a SINCE line: it records when the behaviour appeared;
- `joins.md` "Since engine 0.23.0 with arrow-extensions 0.3.3" — already the
correct pair for this train;
- the subquery/CTE limitation statements — still TRUE (see below).
Found while sweeping — README was stale by TWO releases: its JDBC driver table
and all three coordinate blocks still said 0.3.1 while `documentation/client/
jdbc.md` said 0.3.2, so the 0.3.2 sweep had missed README. Also
`community-extensions` was deliberately held at 0.3.1 last train because the
extensions repo had not moved; it has now, so it bumps to 0.3.2 here.
`install.cmd` carries the RELEASE RITUAL, which is functional and not
documentation: PS1_REF v0.22.0 -> v0.23.0 AND PS1_SHA256 recomputed from the
real tag (9a7c772c…), because a bumped ref with a stale hash is a hard failure
for every install.cmd-only user. Method controlled first: the hash pinned before
this change matches v0.22.0's install.ps1 byte for byte. Patched as BYTES —
`.gitattributes` marks `*.cmd -text`, so a text-mode rewrite silently converts
CRLF and turns a 3-line edit into 330.
`repl.md`'s installer listing is a quoted product output, so it was RE-CAPTURED
by running `./install.sh --list-versions --es-version 8` rather than retyped: it
now shows 7 versions ending at 0.23.0. That run also proves the
`softclient4es8-cli-all_2.13` bundle published at 0.23.0 — a missing `-all`
bundle falls back to the plain artifact, which carries no arrow extensions and
therefore no cross-index JOIN.
⚠️ No wording claims derived tables or subqueries EXECUTE. Story 22.1 makes
`FROM (SELECT ...) AS d` PARSE and be refused with HTTP 400 where the relational
engine is absent; execution is story 22.4. The existing "no arbitrary
subqueries" statements stay correct and untouched.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
fupelaqu
marked this pull request as ready for review
September 14, 2026 20:16
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Version sweep for the 0.23.0 train: core/repl
0.23.0· extensions0.3.2· arrow0.3.3· jdbc0.3.3.Companion PR in
softclient4es-websweeps the same numbers on the public site.Verified before writing, not after
Every version written here returned 200 on JFrog first — jdbc + adbc drivers for es6/7/8/9 at
0.3.3,softclient4es8-java-clientat0.23.0,arrow-extensions0.3.3,community-extensions0.3.2. That check exists because an earlier sweep shipped a doc that installed a version which never shipped, and the failure is silent.Per-occurrence triage, not a blanket replace
Deliberately NOT bumped — each of these looks identical to a regex and means something different:
joins.md"since arrow-extensions 0.2.5 (REPL bundle0.20.4, driver0.2.5)"joins.md"Since engine0.23.0with arrow-extensions0.3.3"Found while sweeping
0.3.1whiledocumentation/client/jdbc.mdsaid0.3.2— the 0.3.2 sweep had missed README entirely.community-extensionswas held at0.3.1deliberately last train (the extensions repo had not moved). It has now, so it bumps to0.3.2here — a deliberate non-bump becoming a bump.install.cmd— the release ritual, which is functional, not documentationPS1_REFv0.22.0→v0.23.0andPS1_SHA256recomputed from the real tag (9a7c772c…). A bumped ref with a stale hash is a hard failure for everyinstall.cmd-only user, so the two always move together.Method controlled first: the hash pinned before this change matches
v0.22.0'sinstall.ps1byte for byte, which is what makes the new value trustworthy.🔴 Patched as bytes.
.gitattributesmarks*.cmd -text, so a text-mode rewrite silently normalises CRLF and turns a 3-line edit into 330. The diff here is 3 lines and the file is still CRLF.repl.md's version listing was re-captured, not retypedIt is quoted product output, so it was regenerated by actually running
./install.sh --list-versions --es-version 8. It now shows 7 versions ending at0.23.0.That run also proves the
softclient4es8-cli-all_2.13bundle published at0.23.0— worth stating, because a missing-allbundle falls back to the plain artifact, which carries no arrow extensions and therefore no cross-index JOIN. The docs would demonstrate the path that loses the headline feature, silently.Nothing here claims derived tables or subqueries execute. 22.1 makes
FROM (SELECT …) AS dandJOIN (SELECT …) AS d ON …parse and validate, then be refused with HTTP 400 wherever the relational engine is absent. Execution is story 22.4. The existing "no arbitrary subqueries" / "subqueries, CTEs … not supported" statements remain correct and are untouched.