Document that migrations are supported and none are added before 1.0 (closes #68) #205

Merged
clawbot merged 1 commits from issue-68-migrations-supported into next 2026-09-28 20:21:39 +02:00
Collaborator

Reworks #68 after the owner's correction (#68 (comment)). #146 called the numbered schema files a bootstrap only and said vaultik has no upgrade path between versions. That was wrong.

What changed

  • docs/DATAMODEL.md has a new "Schema Migrations" section that owns the explanation. The files in internal/database/schema/ are migrations, schema_migrations records which have run, and database.New applies any that have not. None are added before 1.0 because nothing is installed anywhere yet, so a schema change edits 001.sql directly. After 1.0, each change is a new numbered file, and an existing local database is migrated when vaultik is updated.
  • The README caveat, the README roadmap entry and AGENTS.md policy 13 now say the same thing briefly and link to that section.
  • The README caveat keeps one practical note: before 1.0, an update can leave the local index unusable, and vaultik database delete plus a full backup rebuilds it.

Disclosures

  • CLAUDE.md is the owner's file. Only line 33 changes, from "We do not need to support migrations" to "We do not add migrations before 1.0".
  • make fmt formats only Go in this repo, so I wrapped the markdown by hand to match each file.

Model: opus-5-5

Reworks https://git.eeqj.de/sneak/vaultik/issues/68 after the owner's correction (https://git.eeqj.de/sneak/vaultik/issues/68#issuecomment-103097). https://git.eeqj.de/sneak/vaultik/pulls/146 called the numbered schema files a bootstrap only and said vaultik has no upgrade path between versions. That was wrong. ## What changed - `docs/DATAMODEL.md` has a new "Schema Migrations" section that owns the explanation. The files in `internal/database/schema/` are migrations, `schema_migrations` records which have run, and `database.New` applies any that have not. None are added before 1.0 because nothing is installed anywhere yet, so a schema change edits `001.sql` directly. After 1.0, each change is a new numbered file, and an existing local database is migrated when vaultik is updated. - The README caveat, the README roadmap entry and `AGENTS.md` policy 13 now say the same thing briefly and link to that section. - The README caveat keeps one practical note: before 1.0, an update can leave the local index unusable, and `vaultik database delete` plus a full backup rebuilds it. ## Disclosures - `CLAUDE.md` is the owner's file. Only line 33 changes, from "We do not need to support migrations" to "We do not add migrations before 1.0". - `make fmt` formats only Go in this repo, so I wrapped the markdown by hand to match each file. Model: opus-5-5
clawbot added the needs-review label 2026-09-28 20:12:06 +02:00
clawbot self-assigned this 2026-09-28 20:12:06 +02:00
clawbot added 1 commit 2026-09-28 20:12:06 +02:00
#146 called the numbered schema
files a bootstrap and said vaultik has no upgrade path between versions.
That was wrong: they are migrations, and database.New applies any the
database has not recorded. None are added before 1.0 because nothing is
installed anywhere yet; after 1.0 each schema change is a new numbered
file and the local database is migrated on update.

docs/DATAMODEL.md gets a Schema Migrations section that owns the
explanation. The README caveat and roadmap entry and AGENTS.md policy 13
say the same and link to it. CLAUDE.md, the owner's file, gets a
one-line edit so it no longer says migrations are not needed.

Model: opus-5-5
Author
Collaborator

Review passed.

Model: opus-5-5

Review passed. Model: opus-5-5
clawbot merged commit 6e1f499048 into next 2026-09-28 20:21:39 +02:00
clawbot deleted branch issue-68-migrations-supported 2026-09-28 20:21:39 +02:00
clawbot removed the needs-review label 2026-09-28 20:21:43 +02:00
Sign in to join this conversation.