docs: the development line is 0.9.0-dev, not 0.10.0-dev - #420
Conversation
v0.9.0 was prepared (workspace bump, release notes) but never tagged or published — v0.8.1 remains the latest release. The docs nevertheless treated 0.9.0 as a completed boundary: they claimed v9 maps to 'the first published release line', told operators to export v9 graphs 'with the latest 0.9.x binary' (a binary that does not exist), and labeled every stamp since v10 as a '0.10.0-dev' line whose binaries actually identify as 0.9.0. Relabel throughout: v9 joins v5-v8 as an unpublished 0.9.0-dev format with source-build export guidance, v10-v19 are 0.9.0-dev, and the release gate is 0.9.0. Merge the rolling 'v0.10.0' release notes into docs/releases/v0.9.0.md as one draft for the actual upcoming release (spanning everything since 0.8.1) and delete v0.10.0.md. Deliberately out of scope (docs describe it honestly instead): the in-code release map still labels stamp 9 as '0.9.x' inside refusal messages, and the grammar tests plus the env-gated v9 crossversion seam pin those exact strings. That relabel changes pinned test strings and is annotated as release-prep work next to the existing arm-split note in migrations.rs.
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| renames, substrate-native key-conflict fencing, and crash recovery for every | ||
| writer — plus the experimental streaming-profile line described in the | ||
| sections further below. This file is the rolling draft for the unreleased | ||
| 0.9.0 line; every development build since v0.8.1 identifies as 0.9.0. |
There was a problem hiding this comment.
The workspace remained at 0.8.1 until the later release-preparation bump, so this sentence incorrectly says the source builds that wrote earlier development formats identified as 0.9.0. That mismatch makes historical binaries harder to identify when rebuilding v5–v8 graphs.
Knowledge Base Used: Dev conventions and invariants
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
| | internal schema v17 | unreleased (earlier 0.10.0-dev source builds) | final v17 source build at merge `41a5990d53238d63d17e139859c66613f9c25867` | | ||
| | internal schema v18 | unreleased (earlier 0.10.0-dev source builds) | final v18 source build at merge `c7c81b186bed37989fe5ce591baf0965b5102648` | | ||
| | internal schema v19 | unreleased (current 0.10.0-dev source builds) | — current development format; a later pre-release strand may supersede it | | ||
| | internal schema v9 | no published release (0.9.0-dev source builds; the refusal label still reads `0.9.x`) | a source build at the matching commit | |
There was a problem hiding this comment.
When an operator needs to export a schema-v9 graph, the refusal supplies only 0.9.x and this row now requires a source build at an unspecified matching commit. Because no 0.9.x binary was published and no immutable final-v9 revision is given, the operator cannot obtain the binary required to perform the documented rebuild.
Knowledge Base Used: Dev conventions and invariants
1 participant
What changed
docs/releases/: merged the rolling "v0.10.0" notes intov0.9.0.mdas one draft for the actual upcoming release (everything since 0.8.1; header now says unreleased — rolling draft; a bridge note explains the former v0.10.0 heading), deletedv0.10.0.md. Corrected the old text's claims that the release stamps v9 ("advances from v4 to v9" → to the current stamp, v19 at writing) and that "a published binary only ever wrote v4 or v9" (only v4 or earlier — 0.9.x never shipped).upgrade.md: the v9 table row no longer claims a published 0.9.x line ("export with the latest 0.9.x" pointed at a binary that doesn't exist); v9 gets the same source-build-at-matching-commit guidance as v5–v8, and the v9→v10 migration recipe says "final-v9 source build." All "0.10.0-dev" labels → "0.9.0-dev"; "final 0.10.0 format" → "final 0.9.0 format."versioning.md: the load-bearing false sentence — "Internal schema v9 maps to OmniGraph 0.9.x — the first published release line to serve any of these formats" — replaced with the truth (release prepared at v9, never published; only source builds serve it), with an honest note that the in-code release map still says0.9.xpending the release-prep relabel. Nine stanza labels 0.10.0-dev → 0.9.0-dev.testing.md: the v9-seam paragraph stops calling 0.9.x "published" while keeping the literal pinned strings it documents accurate to the code; two 0.10.0-dev mentions relabeled.firehose-path-specs.md: "0.10.0 release gate" → "0.9.0 release gate" (×2).Why
v0.8.1 is the latest actual release. 0.9.0 was prepared (
a2215f60workspace bump + notes) and never tagged, so every development build since — including the one stamping v19 graphs today — identifies as 0.9.0. The docs' "0.10.0-dev" line named a release line that doesn't exist, and worse, the v9 guidance sent operators looking for a published 0.9.x binary that was never built.Deliberately out of scope
The code half of the same problem:
release_for_internal_schema_versionstill maps9 => "0.9.x"(with a now-false "published line" comment) and10..=19 => "0.10.0-dev", and those exact strings are pinned by the in-file grammar tests and the env-gated v9 crossversion seam. Changing them is a coordinated code+test change and is annotated as release-prep work next to the existing arm-split instruction inmigrations.rs; the docs touched here describe that pending state honestly rather than pretending it's done.Validation
scripts/check-agents-md.sh— OK (73 links, 69 docs)--no-renamesclassifier fix, since it deletes a docs file)Greptile Summary
Corrects the documented development release line from 0.10.0-dev to 0.9.0-dev and consolidates the rolling release notes under v0.9.0.
Confidence Score: 4/5
The final-v9 upgrade instructions should identify an immutable compatible commit before merging; the remaining release-history wording issue is non-blocking.
The PR fixes the release-line history, but operators with schema-v9 graphs are still directed to a source build that neither the refusal output nor the documentation makes locatable.
Files Needing Attention: docs/user/operations/upgrade.md, docs/releases/v0.9.0.md
Important Files Changed
Reviews (1): Last reviewed commit: "docs: the development line is 0.9.0-dev,..." | Re-trigger Greptile
Context used: