Repository navigation
26.11.1.post4: scope, gates and schedule #401
Description
This is the plan and the gates for 26.11.1.post4, the release of all the glue work that follows 26.11.1.post3. The scope is all glue, not only the paths of the benchmark cells: every JSON text that crosses between Java and Python on a bulk or per-row path (#388), and the small per-call overheads that the CRUD audit found. The engine stays byte-identical to 26.11.1, as in post1 to post3.
Candidates, all drafts from the tag 26.11.1.post3, tests first, none of them measured yet: #389 native count(), #390 native create_vertices as a frame, #391 JVM graph_batch typed columns, #392 JVM insert_many typed columns, #393 native async create_record batch, #394 frame kinds for RID and number lists, #395 JVM get_rid readers, #396 JVM new_edge, #397 native reply tail and the dead entry, #398 native approximate vector search by pointer. #390 and #391 come first because the graph loads of the benchmark cells (create_vertices) run through them. I dropped the native columnar head frame (rank 4 of #388): by sizing it saves 0.03 to 0.34 ms per call and needs an API change.
What post3 taught me, and what changes for post4: its timed study had no figure for the exact shape of the benchmark cell that regressed (#400: a single-record UPDATE through command() in a begin and commit pair is about 26 percent slower than on 26.11.1), and it labelled one figure with the wrong auto-transaction mode. So the post4 study has a figure for the operation shape of every benchmark cell that a PR can touch, on both wheels, next to the figures of the PRs, and every figure is checked against the code path that it runs before it is credited to a PR.
Gates, all of them before a tag:
- the full CI matrix (all legs, both wheels) is green on the integration branch, which holds exactly the candidates that go in; the draft pull requests only run the light checks (the heavy legs are skipped on them), so one full run of the branch that ships replaces ten runs of the branches that do not
- a parity digest per figure: the stored data and the returned values are identical between the arms
- a pre-registered timed A/B per candidate against the released post3 wheel (ABBA, A/A control, latency and peak memory), and the figures of the benchmark cells as a regression guard; a candidate with a figure that is slower than post3 stays out
- the integration branch from the tag with the candidates that passed, its CI-built wheels measured as a whole (the gate run, as for post3)
- the same wheels and the published
26.11.1, post2 and post3 measured side by side, solo on the mini, before the cherry-pick tomain(post1 is left out: its native wheel was never published); each candidate marked in or out with the figure that decided it (post4: confirm each candidate solo on the mini against 26.11.1, post2 and post3, then cherry-pick only what passes #405) - the engine identity guard on the CI-built and on the published wheels
- Native: single-record UPDATE through command() is about 26 percent slower on post3 than on 26.11.1 in the l1tpc paper cells #400 is understood, and fixed in post4 or named as open in the release notes
- the docs describe what the tag contains and only the figures that were measured
Resources: CI is the authority for the full matrix. The laptop timed lane runs the A/B studies. The mini builds and tests the branches with Docker while it is idle (the first Java compile does not wait for the shared runner pool) and runs the benchmark cells solo. More timed lanes on the laptop and the mini come after their qualification (tracked in the control plane).
Schedule (estimates, not promises): first compile and test fixes of the candidates on 2026-11-15 and 16; the A/B studies on 2026-11-16 to 18; go or no-go on 2026-11-19; the tag on 2026-11-19 or 20; the mini reruns of the affected benchmark cells (graph loads on both wheels, about 8 hours) on 2026-11-20 and 21; landing on the page and in the paper notes on 2026-11-22 and 23; the paper deadline is 2026-11-24. A candidate that is not ready on the 19th goes into a later release.
Activity
tae898 commentedon Nov 14, 2026
Status of the ten candidates on 2026-11-14, evening. Every branch now has a CI-built wheel at its final head and a pre-registered per-candidate A/B in the timed queue. They wait for the A/A study, which is in its last rounds; it runs the released
26.11.1.post3wheel on both sides and validates the figures, the path probes and the scorer, not any candidate.Five branches had never run their new code in a full CI matrix, and the first matrix found real problems. #391 failed on a stale
tests/test_import_database.pyfrom the tag against the movinglatestengine image (it now takes the file frommain). #392 had a real parity gap: a row holding a NaN, an infinity or a subnormal double stored its whole numbers asIntegerwhere the old route storesLong; fixed in85332a9. #395 called the bridge class in the new getters without the fallback that every other reader has; fixed in84849b5. #393 and #396 had mistakes in their own tests, and the code of both is unchanged. #394 is green on the JVM wheel and on every Linux and macOS job of the native build; its Windows image build failed on a Maven Central fetch and I will re-run it before any merge. A JVM dispatch for an A/B now passes-f arcadedb-tag=26.11.1: the default takes the jars from thelatestimage, which is another engine.One change to the plan comes from #404. The native wheel on PyPI is a rebuild, and two builds of one commit differed by about 32 percent on the single-record
UPDATEin the cell's process state. So the A arm of every native run is the CI-builtpost3wheel, not the published one. A native guard figure that moves by 15 percent or more while the candidate's own figures are flat is flagged BUILD-SUSPECT, and the same commit is built again before the candidate is judged. The release gets a canary on the publishedpost4wheel too, with the cell shape as the figure.The schedule is as before: the per-candidate runs take about eight hours after the A/A study, the integration run follows, and the go or no-go is on 2026-11-19. Related: #404, #400.
tae898 commentedon Nov 15, 2026
Added one gate to the list above: the integration wheels and the published
26.11.1, post1, post2 and post3 measured side by side, solo on the mini, before the cherry-pick tomain(#405). Edits send no notification, so this comment says it.tae898 commentedon Nov 15, 2026
Changed the first gate above: the full CI matrix runs once on the integration branch (the one that ships), not on each of the ten draft branches. The drafts only run the light checks of a pull request (15 heavy legs are skipped on every one of them), so ten full runs would cost most of a day of runner time for branches that never ship as such, and the integration run is the stronger test because it covers the candidates together. A candidate that the integration run implicates still gets its own full run. Edits send no notification, so this comment says it.
Native create_vertices: a chunk of fewer than 64 rows keeps the JSON …
Native async create_record: the first 32 records of an executor go on…
Native create_vertices: the comment of the 64 row floor names the mic…
Tests: a def in the floor test, not an assigned lambda (ruff E731 of …
Native async create_record: a hand-over of fewer than 64 collected re…
Tests: nosec B404 and B603 on the subprocess of the floor-from-enviro…
tae898 commentedon Nov 15, 2026
The in or out rule for the candidates, written before the last verdicts are in (so that no verdict decides its own rule):
Where this stands: #393 and #395 (with its fix) are in unless the re-runs say otherwise; #390 is in if its small-batch fix clears
n_gb_v_1and the guardn_l2_read_pointis not slower on the new build; #389, #391, #392, #396, #397 are pending the mini and the replicates; #394 and #398 are not measured yet.Native async create_record: the first 96 records of an executor go on…
Native async create_record: the first 128 records of an executor go o…