Skip to content

docs: bring user-facing versions up to the 0.20.3 release train - #194

Merged
fupelaqu merged 1 commit into
mainfrom
docs/versions-0.20.3
Aug 4, 2026
Merged

docs: bring user-facing versions up to the 0.20.3 release train#194
fupelaqu merged 1 commit into
mainfrom
docs/versions-0.20.3

Conversation

@fupelaqu

@fupelaqu fupelaqu commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Post-release documentation sweep for the 0.20.3 train.

Version bookkeeping

Every version below was checked against JFrog before being written, not inferred from the train:

what from to
jdbc-driver / adbc-driver / arrow-flight-sql 0.2.3 0.2.4
community-extensions 0.2.2 0.2.3
arrow-extensions 0.2.3 0.2.4
java-client (engine) 0.20.2 0.20.3
installer examples + bundle-version list 0.20.1 / 0.20.2 0.20.3

The 0.20.2 sweep had to fix a doc that installed a version which never shipped, and the failure mode is quiet: a version with no -all bundle silently falls back to the plain artifact, which has no arrow extensions and therefore no cross-index JOIN. The docs would be demonstrating the path that loses the headline feature. So softclient4es{6,8,9}-cli-all_2.13:0.20.3, *-adbc-driver:0.2.4, *-arrow-flight-sql:0.2.4, *-jdbc-driver:0.2.4 and softclient4es8-java-client_2.13:0.20.3 were each confirmed 200 first.

Two corrections that are not bookkeeping

1. dml_statements.md told 0.20.3 users their own release was broken.

It said "releases up to and including 0.20.3 fail on JDK 23 and newer" for PARQUET, DELTA_LAKE and remote schemes — sitting directly beneath a table stating those work on every JDK. The boundary is 0.20.2, confirmed from the published POMs rather than the commit title:

core_2.13-0.20.3.pom   hadoop-client 3.4.3   ← HADOOP-19212, the fix
core_2.13-0.20.2.pom   hadoop-client 3.4.2

2. materialized_views.md quoted a watcher warning that is not the one that ships.

The doc's version named the licence as the cause. The shipped wording deliberately names no cause, because the licence is only one of two ways to reach it — the other is a cluster with no usable webhook credentials, which is exactly what xpack.security.enabled: false gives you (the default local, CI and testkit setup). The real cause is quoted verbatim after Reason:.

Replaced with the exact output captured from the -all bundle against a basic cluster, and documented the second cause — plus the boundary that keeps the degradation honest: a wrong credential still fails loudly, because that is a fixable typo, not a missing capability.

Left alone

Historical statements: since v0.14.0 feature markers and CONTRIBUTING's release-process example describe the past, not what to install.

ThisBuild / version stays at 0.20.3. This repo bumps to the next -SNAPSHOT with the first post-release change rather than in a dedicated commit — say the word if you would rather open 0.20.4-SNAPSHOT here.

Every version below was checked against JFrog before being written — the
0.20.2 sweep had to fix a doc that installed a version which never shipped,
and a version with no -all bundle silently falls back to the plain artifact,
which has no arrow extensions and therefore no cross-index JOIN.

  jdbc-driver / adbc-driver / arrow-flight-sql   0.2.3  -> 0.2.4
  community-extensions                          0.2.2  -> 0.2.3
  arrow-extensions                              0.2.3  -> 0.2.4
  java-client (engine)                          0.20.2 -> 0.20.3
  installer examples + bundle-version list      0.20.1/0.20.2 -> 0.20.3

Two corrections that are not version bookkeeping:

1. dml_statements.md said "releases up to and including 0.20.3 fail on JDK 23
   and newer" for PARQUET, DELTA_LAKE and remote schemes — directly under a
   table stating those work on every JDK. The boundary is 0.20.2: the
   published core 0.20.3 POM pins hadoop-client 3.4.3 (0.20.2 pinned 3.4.2),
   and HADOOP-19212 is the fix. As written it told current users their own
   release was broken.

2. materialized_views.md quoted a watcher warning that is not the one that
   ships. The wording deliberately names NO cause, because the licence is
   only one of two ways to reach it — the other is a cluster with no usable
   webhook credentials, which is what `xpack.security.enabled: false` gives
   you, the default local/CI/testkit setup. The real cause is quoted verbatim
   after `Reason:`. Replaced with the exact output, captured from the -all
   bundle against a basic cluster, and added the second cause plus the
   boundary that keeps it honest: a WRONG credential still fails loudly,
   because that is a fixable typo, not a missing capability.

Historical statements left alone: "since v0.14.0" feature markers and
CONTRIBUTING's release-process example describe the past, not what to install.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@fupelaqu
fupelaqu merged commit d4e3ee9 into main Aug 4, 2026
2 of 4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant