You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Six manual and getting-started pages (sample output)
9 live, 6 historical in the upgrade manual
tests/test_cli_vector_catalog_migration.py
6
The most recent catalog bump touched twelve files, two of which were the constants. The tripwire tests catch drift, but they do so by making each bump larger rather than smaller. The thirty version strings in the three notices files are the workspace's own extenddb-* crates, so every workspace bump regenerates three committed files and notices-current fails until someone does it (#271, #272, #341 are all this).
Proposed solution
In order of payoff:
Exclude workspace member crates from the generated third-party notices. They are Apache-2.0 first-party code, not third-party notices. After this a workspace bump produces no notices diff. Needs the mechanism the pinned cargo-about offers for ignoring workspace or private crates, or a filter in about.hbs; a rule ("workspace members") is preferable to a name list.
One catalog constant in extenddb-core, used by both backends. The SQLite seed writes the version with a parameterised upsert after the schema is applied instead of a literal inside SCHEMA_SQL. The PostgreSQL migrator writes the version from Rust after sqlx::migrate! completes, so future migration files stop carrying an UPDATE settings. Existing migration files are not edited (sqlx checksums applied migrations); the UPDATE in 003 stays and is harmless. The tripwire tests move from "literal equals constant" to "catalog reads the constant back".
tests/test_cli_vector_catalog_migration.py reads the expected catalog version from extenddb version output instead of six literals.
A check that packaging/npm/package.json matches Cargo.toml, or generating its six version fields at publish time in the npm workflow.
Reduce the sample-output blocks that print versions to one per document, keeping doc_version_literals.rs for what remains.
After 1 and 2 a workspace bump is Cargo.toml plus one documentation block, and a catalog bump is one constant plus one documentation block.
Alternatives considered
Keep the current layout and rely on the tripwire tests. They work, but they enforce consistency by forcing every bump to touch every copy, which is the complaint.
A single VERSION file read by everything. Cargo already owns the workspace version and cargo-about reads Cargo metadata, so a second file would add a copy rather than remove one.
DynamoDB API reference
Not applicable; build and release tooling only.
Additional context
Item 2 has one hard constraint: never edit an applied PostgreSQL migration file. The change has to go into the migrator, not into migrations/001 through 003.
Checklist
I have searched existing issues and the roadmap for duplicates
I have described the use case, not just the desired implementation
Problem or use case
Two version numbers are spelled out by hand in many places, and bumping either one touches far more files than its source of truth.
Workspace version (
0.1.11), source of truthCargo.toml:Cargo.toml[workspace.package]packaging/npm/package.json(package version plus five platform-package pins)Cargo.tomlSOFTWARE-LICENSE-NOTICES.html,-DEV.html,-MONGODB.htmlcargo-about, committed;notices-currentfails when staledocs/getting-started.md,docs/manuals/04-quickstart-setup-guide.mdcrates/storage-postgres/tests/doc_version_literals.rsfails on driftCatalog version (
0.0.4):crates/storage-postgres/src/lib.rsandcrates/storage-sqlite/src/schema.rs, one constant eachSCHEMA_SQLseed literal; PostgreSQL migration closingUPDATE settingstests/test_cli_vector_catalog_migration.pyThe most recent catalog bump touched twelve files, two of which were the constants. The tripwire tests catch drift, but they do so by making each bump larger rather than smaller. The thirty version strings in the three notices files are the workspace's own
extenddb-*crates, so every workspace bump regenerates three committed files andnotices-currentfails until someone does it (#271, #272, #341 are all this).Proposed solution
In order of payoff:
cargo-aboutoffers for ignoring workspace or private crates, or a filter inabout.hbs; a rule ("workspace members") is preferable to a name list.extenddb-core, used by both backends. The SQLite seed writes the version with a parameterised upsert after the schema is applied instead of a literal insideSCHEMA_SQL. The PostgreSQL migrator writes the version from Rust aftersqlx::migrate!completes, so future migration files stop carrying anUPDATE settings. Existing migration files are not edited (sqlx checksums applied migrations); theUPDATEin 003 stays and is harmless. The tripwire tests move from "literal equals constant" to "catalog reads the constant back".tests/test_cli_vector_catalog_migration.pyreads the expected catalog version fromextenddb versionoutput instead of six literals.packaging/npm/package.jsonmatchesCargo.toml, or generating its six version fields at publish time in the npm workflow.doc_version_literals.rsfor what remains.After 1 and 2 a workspace bump is
Cargo.tomlplus one documentation block, and a catalog bump is one constant plus one documentation block.Alternatives considered
notices-currentchecks on every pull request somainnever becomes unreleasable.VERSIONfile read by everything. Cargo already owns the workspace version andcargo-aboutreads Cargo metadata, so a second file would add a copy rather than remove one.DynamoDB API reference
Not applicable; build and release tooling only.
Additional context
Item 2 has one hard constraint: never edit an applied PostgreSQL migration file. The change has to go into the migrator, not into
migrations/001through003.Checklist