Publish previews from a tag on main, and cut 1.0.0-preview.1 - #29
Merged
Merged
Conversation
`org.chdb` is not on Central yet, so there is nowhere for a user to resolve the driver from. This publishes a release as GitHub Release assets instead: one zip per platform, holding the jars and the POMs the build produced, and scripts/install-preview.sh installs one into a local Maven repository with `install-file`. The workflow is the Central path with the last step swapped -- the same four runners, the same build-native.sh, the same integration tests against the staged package -- and it keeps release.yml's rule that the version lives in git: no `versions:set` in CI, the POMs at the tagged commit must already carry the tag's version, scripts/check-release-tag.sh must agree that the tag names that commit, the commit must be an ancestor of main, and `build` must have concluded successfully for it. Each of those checks names a way the first preview went wrong. v1.0.0-preview.1 was tagged on a branch 67 commits behind main, so the published binaries were missing thirteen merged fixes -- non-streamable statements, the non-ASCII storage path, the shutdown hook, stream handle ownership, RowBinary types -- and its own install command pointed at a script that existed only on that branch. A preview tag is also excluded from release.yml's trigger. `v*` matched it, and preflight would have accepted it, so the Central path would have staged and signed a preview and offered it in the portal, where a release cannot be unpublished. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
… resolve yet The Maven coordinates at the top of Installing are the ones a user will eventually write, and today they resolve to nothing. Say so where they are, and give the path that works: the installer script, what it verifies, and the coordinates it prints. Versioning gains the preview qualifier -- `26.7.3.1-preview.1` is the first preview of `26.7.3.1` and sorts below it -- so a preview stays the same scheme from a different place rather than a second one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
`<engine-version>.<binding-revision>` read the wrong way round in both directions. The move from 26.7.2-rc.2.1 to 26.7.3.1 looked like a major change and was none of the binding's doing, while a break in the Java API could ship as a trailing `.2` that nothing in the number marked as breaking. A version is read by consumers, and the question they ask it is about the Java API. So: SemVer for the binding, `1.0.0` first, `1.0.0-preview.<n>` for a preview. The engine version is not dropped, it is moved to where it can be read rather than parsed out of a string -- `engine.version` in each native package's manifest.properties, the pinned baseline and its SHA-256 in scripts/engine.properties, and the release notes. The ABI check already refuses any engine but the one a package was built against, so the pairing was never the artifact name's job. Work plan §4.3 is rewritten rather than annotated, because a versioning rule with two answers in it is worse than either. The README also says plainly that `org.chdb` itself is provisional and may end up as `com.clickhouse`. A preview survives that: the bundle carries the POMs it was built with and the installer reads the group id out of them, so a namespace decision changes what a user declares, not whether an install keeps working. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…blishing Two gaps in the preview workflow, both found in review. The bundle check installed the artifacts and then ran a class off a hand-built `-cp`. That proves the JARs execute and says nothing about whether Maven can resolve them, which is the half `install-file` can break: the parent relationship, the BOM's dependencyManagement, and the native package's dependency on the driver are all metadata a classpath never reads. scripts/verify-preview-bundle.sh builds a project outside the checkout instead, declaring the native package and no version and resolving from nothing but the repository the bundle was installed into, then runs an in-memory query and one that has to survive a reopen. It also asserts every org.chdb artifact on the classpath came from that repository. Running it locally against the published bundle turned up a bug in it worth keeping the note: `jar --create` writes its own META-INF beside the bundle directory, so "the first directory in the zip" is not the bundle. The publish job had no checkout. Every gh call in it passes --repo, so it had a good chance of working, but `gh release create` with no --repo and no checkout is exactly how the first attempt at publishing a preview failed -- `fatal: not a git repository` -- and a job that publishes is the wrong place to rely on a flag being right. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The tag has to name bytes a commit describes, so the version is committed here rather than set in CI. The back-to-development commit returns the POMs to a -SNAPSHOT after the tag is pushed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ShawnChen-Sirius
force-pushed
the
release/preview-publishing
branch
from
September 21, 2026 00:26
aea066b to
d1cb70b
Compare
ShawnChen-Sirius
changed the title
Five things review found, each able to publish or install something wrong. The publish job re-resolves the tag immediately before uploading and fails unless it still points at the commit the bundles were built from. `--verify-tag` only asks whether the tag exists, and staging takes tens of minutes -- long enough for a tag to move. `gh release edit` passes `--draft=false`, so an existing draft is published rather than quietly taking the uploads and staying invisible. The integration-test step closes stdin, as build.yml already does: chDB reads a non-TTY stdin with bytes on it as external data for an INSERT. verify-preview-bundle.sh does the same, because its consumer inserts. In the installer, `$HOME` is no longer dereferenced under `set -u` before arguments are parsed, and a relative `--maven-repo` is made absolute before Maven runs from the temporary directory -- it used to install into a path the EXIT trap deleted, then report success. Comments here are cut to what is not obvious from the code. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`1.0.0-preview.1` does not sort below `1.0.0`. ComparableVersion orders unknown qualifiers
after the final release, and `preview` is not one of the qualifiers it knows, so the preview
compares *newer* than the release it previews. Measured against maven-artifact 3.9.9:
1.0.0-preview.1 > 1.0.0
1.0.0-rc.1 < 1.0.0
The README and §4.3 claimed the opposite. Both now say what it does, and why it costs
nothing as things stand -- previews are installed by hand into a local repository, never
published beside a GA, and named exactly rather than matched by a range -- with `-rc.<n>` as
the answer if one ever has to live in a shared repository.
The prose around all of this is cut back too.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
Author
|
Review findings, all addressed in f8822b9 and ae0e23b.
Prose and comments across the PR are also cut back: 213 lines removed against 135 added, no behaviour change in that commit. |
Contributor
Author
|
@wudidapaopao please reivew this PR |
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
1 participant
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.
v1.0.0-preview.1was tagged on a branch 67 commits behindmain, so the binaries itpublished were missing thirteen merged fixes, and the install command in its README pointed
at
main/scripts/install-preview.sh— a path that only ever existed on that branch, so thefirst step of the documented install returned 404. Verified against the published assets on
Linux x86_64:
DESCRIBE/SHOW/EXPLAIN/EXISTSall fail with Streaming query is notsupported (#12), a non-ASCII storage path is refused under a non-UTF-8 locale (#7), exiting
the JVM with a live stream aborts with a libc++ assertion, exit 134 (#8, #22), and column
types come back as the Arrow projection rather than what the engine declared —
DateTimeasUInt32,ArrayasUnsupported(arrow=+l)(#28).Nothing had downloaded it, so it is withdrawn and the number reused. This brings the
publishing machinery onto
mainand makes that class of release impossible to cut again.What is here
.github/workflows/preview-release.yml— the Central path with the last step swapped.Same four runners, same
build-native.sh, same integration tests against the staged package;instead of signing a portal bundle it uploads one zip per platform to a GitHub Release. It
keeps
release.yml's rule that the version lives in git — noversions:setin CI — andrefuses a tag unless all four hold:
scripts/check-release-tag.shagrees the tag points at this commitmaincompare/main...e9f2223isdivergedbuildconcluded successfully for the commitscripts/package-preview.sh,scripts/install-preview.sh— moved ontomain, which iswhat the README's
curlneeds. The installer verifies the bundle against the release'sSHA256SUMS, installs the POMs the build produced rather than generated ones, and refuses abundle whose
preview.propertiesversion disagrees with the tag it was fetched under. Its404 message names both plausible causes instead of leaving
curl: (22)as the diagnosis.scripts/verify-preview-bundle.sh— what CI runs on each bundle before it is uploaded. Areal Maven project outside the checkout, declaring the native package with no version and
resolving from nothing but the repository the bundle was installed into, so the parent
relationship, the BOM and the transitive
chdb-jdbcdependency are all exercised — then anin-memory query and one that has to survive a reopen.
release.ymlno longer triggers on preview tags.v*matchedv1.0.0-preview.1andpreflight would have accepted it, so the Central path would have staged, signed and offered a
preview in the portal — where a release cannot be unpublished.
Versioning: the binding is now SemVer,
1.0.0-preview.1.<engine-version>.<binding-revision>read the wrong way round in both directions:
26.7.2-rc.2.1→26.7.3.1looked like a majorchange and was none of the binding's doing, while a break in the Java API could ship as a
trailing
.2. The engine version moves to where it is read rather than parsed — each nativepackage's
manifest.properties,scripts/engine.properties, the release notes — and the ABIcheck already refuses any engine but the one a package was built against. Work plan §4.3 is
rewritten to match. The README also says
org.chdbis provisional and may end upcom.clickhouse; a preview is unaffected either way, because the bundle carries its own POMsand the installer reads the group id out of them.
Checked locally
mvn -pl chdb-jdbc -am testat the new version — 178 tests, green.scripts/verify-preview-bundle.shagainst the published bundle: installs, resolves throughthe BOM,
chdb-jdbcarrives transitively, everyorg.chdbartifact comes from the bundle'sown repository, queries run. It found one bug in itself on the way —
jar --createwrites aMETA-INFbeside the bundle directory, so "the first directory in the zip" is not it.install-preview.shagainst the published release, including the 404 and argument paths.maingate, against three real commits:main→identical(accept), amerged ancestor →
behind(accept),e9f2223→diverged(reject).After merge
Tag the merge commit
v1.0.0-preview.1oncebuildis green on it, let this workflowpublish, then the ordinary back-to-development commit returns the POMs to
1.0.0-SNAPSHOT.🤖 Generated with Claude Code
Note
Publish
v*-preview.*tags as GitHub prereleases and cut1.0.0-preview.1v*-preview.*.1.0.0-preview.1across pom.xml and submodule POMs.v*-preview.*tags from the Central release workflow.v*-preview.*tags, so pushing these tags no longer triggers the standard Central release path.Macroscope summarized ae0e23b.