Skip to content

fix(neo4j): hold the graph contract at the shared 2.0.0 baseline - #221

Merged
rahlk merged 1 commit into
mainfrom
fix/graph-schema-version-baseline
Sep 2, 2026
Merged

fix(neo4j): hold the graph contract at the shared 2.0.0 baseline#221
rahlk merged 1 commit into
mainfrom
fix/graph-schema-version-baseline

Conversation

@rahlk

@rahlk rahlk commented Sep 2, 2026

Copy link
Copy Markdown
Collaborator

Problem

The graph SCHEMA_VERSION is a shared cross-analyzer number. codeanalyzer-typescript says so on its own catalog:

// Additive within 2.1.0 — SCHEMA_VERSION moves only when every analyzer re-baselines together.

This analyzer had drifted off it:

analyzer was
python 2.0.0
typescript 2.1.0
java 3.0.0

2.1.0 (L4 SDG overlay) and 2.2.0 (repository-artifact layer) were additive over labels 2.0.0 had already reserved. 3.0.0 — mine, in #220 — claimed a MAJOR re-baseline no sibling agreed to.

It also produced a second, uglier symptom: the graph reported schema_version: 3.0.0 while analysis.json reported schema_version: 2.0.0 for the same analysis, from two fields that share a name and version different things. 3.0.0 read as canonical schema v3, which does not exist.

Fix

Back to 2.0.0, matching python. The javadoc now states the shared-line rule explicitly, so the next change here is recognisable as a cross-repo decision rather than a local one.

The uncomfortable half, recorded rather than papered over

Removing _module is breaking, and while this number stays put a consumer cannot detect that removal from the version alone. That is a real cost, and it is written into the code comment rather than left for someone to discover.

The answer is a coordinated re-baseline across all three analyzers — which is what epic codellm-devkit/.github#50 exists for. Not a unilateral bump here, which is exactly how the drift started.

Verification

graph:  schema_version: '2.0.0'
json:   schema_version: 2.0.0
python: SCHEMA_VERSION = "2.0.0"

No behaviour change: _module still absent (0 occurrences), :JCanNode still present, the prefix-scoped purge from #220 untouched. Suite 509 tests, 1 failure — the pre-existing Docker CodeAnalyzerIntegrationTest.

typescript remains at 2.1.0 and is now the outlier; that belongs to its own epic child (codeanalyzer-typescript#140).

SCHEMA_VERSION on the graph is a shared cross-analyzer number, not this
analyzer's own. codeanalyzer-typescript states the rule on its own catalog --
"SCHEMA_VERSION moves only when every analyzer re-baselines together" -- and
codeanalyzer-python has stayed at 2.0.0 throughout.

This analyzer had drifted off it: 2.1.0 for the L4 SDG overlay, 2.2.0 for the
repository-artifact layer, then 3.0.0 when `_module` was removed. The first two
were additive over labels that 2.0.0 had already reserved, and the third claimed
a MAJOR re-baseline no sibling had agreed to. None was anyone else's to undo, so
the number goes back to 2.0.0 and the javadoc now says the rule out loud, so the
next change here is recognizable as a cross-repo decision rather than a local
one.

The uncomfortable half is recorded in the code rather than papered over:
removing `_module` IS breaking, and while this number stays put a consumer
cannot detect that removal from the version alone. The answer is a coordinated
re-baseline across all three analyzers, which is what the epic exists for -- not
a unilateral bump here, which is exactly how the drift started.

This also stops the graph reporting 3.0.0 while analysis.json reports 2.0.0 for
the same analysis, from two fields that share the name `schema_version` and
version different things. All three now read 2.0.0.

No behaviour change: `_module` is still absent, :JCanNode still present, the
prefix-scoped purge untouched.
@rahlk
rahlk merged commit aab9d53 into main Sep 2, 2026
@rahlk
rahlk deleted the fix/graph-schema-version-baseline branch September 2, 2026 18:39
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