TODO.md's Next Step says the remaining 1.0 scope is the owner's decision and that the release mechanism itself is done and exercised (issue #65). Nothing else stands between the tree and a tag except finishing the units in the 1.0.0 milestone. This issue is the decision.
The proposal
Release v1.0.0 when the 1.0.0 milestone is empty, and the milestone is exactly this:
Explicitly after 1.0 (stays in the README roadmap, no issue): parallel restore downloads, --bwlimit, restore resume, man pages, snapshot diff, the --cron notification hook, schema migrations for the shipped index. Also after 1.0 per my recommendation on issue #94: daemon mode.
Two items in the milestone are the ones I would drop if the scope must shrink: issue #105 (hash-verifying the release Go toolchain, a policy conformance item that does not change what a user gets) and the fault-injection scenarios in issue #72 beyond corrupt and truncated blobs on read (the two that decide whether restore lies).
What needs you
Confirm or amend the scope above. Silence means the manager proceeds with the milestone as it stands.
Say whether AGENTS.md policy 13 ("the local index is disposable until 1.0 ships and is tagged") is meant to flip at the tag. If yes, the first post-1.0 issue is a schema-versioning story; if no, the policy text is amended to say the index stays disposable and database delete is the upgrade path. Issue #68 deliberately does not answer this.
Once the milestone is empty and the milestone PR is merge-ready, merge next to main and push the v1.0.0 tag; the release workflow does the rest.
Model: fable-5-1
`TODO.md`'s Next Step says the remaining 1.0 scope is the owner's decision and that the release mechanism itself is done and exercised ([issue #65](https://git.eeqj.de/sneak/vaultik/issues/65)). Nothing else stands between the tree and a tag except finishing the units in the `1.0.0` milestone. This issue is the decision.
## The proposal
Release `v1.0.0` when the `1.0.0` milestone is empty, and the milestone is exactly this:
Blockers found in the 1.0 review of [issue #119](https://git.eeqj.de/sneak/vaultik/issues/119): the `sqlite3` binary dependency, the `--older-than 6m` retention trap, cross-machine restore, CI on `next`, and the lint-guard rework. Plus the twelve issues already in the milestone: [issue #66](https://git.eeqj.de/sneak/vaultik/issues/66), [issue #67](https://git.eeqj.de/sneak/vaultik/issues/67), [issue #68](https://git.eeqj.de/sneak/vaultik/issues/68), [issue #70](https://git.eeqj.de/sneak/vaultik/issues/70), [issue #72](https://git.eeqj.de/sneak/vaultik/issues/72), [issue #73](https://git.eeqj.de/sneak/vaultik/issues/73), [issue #74](https://git.eeqj.de/sneak/vaultik/issues/74), [issue #75](https://git.eeqj.de/sneak/vaultik/issues/75), [issue #87](https://git.eeqj.de/sneak/vaultik/issues/87), [issue #96](https://git.eeqj.de/sneak/vaultik/issues/96), [issue #105](https://git.eeqj.de/sneak/vaultik/issues/105), [issue #112](https://git.eeqj.de/sneak/vaultik/issues/112).
Explicitly after 1.0 (stays in the README roadmap, no issue): parallel restore downloads, `--bwlimit`, restore resume, man pages, `snapshot diff`, the `--cron` notification hook, schema migrations for the shipped index. Also after 1.0 per my recommendation on [issue #94](https://git.eeqj.de/sneak/vaultik/issues/94): daemon mode.
Two items in the milestone are the ones I would drop if the scope must shrink: [issue #105](https://git.eeqj.de/sneak/vaultik/issues/105) (hash-verifying the release Go toolchain, a policy conformance item that does not change what a user gets) and the fault-injection scenarios in [issue #72](https://git.eeqj.de/sneak/vaultik/issues/72) beyond corrupt and truncated blobs on read (the two that decide whether restore lies).
## What needs you
1. Confirm or amend the scope above. Silence means the manager proceeds with the milestone as it stands.
2. Say whether `AGENTS.md` policy 13 ("the local index is disposable until 1.0 ships and is tagged") is meant to flip at the tag. If yes, the first post-1.0 issue is a schema-versioning story; if no, the policy text is amended to say the index stays disposable and `database delete` is the upgrade path. [Issue #68](https://git.eeqj.de/sneak/vaultik/issues/68) deliberately does not answer this.
3. Once the milestone is empty and the milestone PR is `merge-ready`, merge `next` to `main` and push the `v1.0.0` tag; the release workflow does the rest.
Model: fable-5-1
clawbot
added this to the 1.0.0 milestone 2026-09-21 09:19:44 +02:00
sneak
was assigned by clawbot2026-09-21 09:19:44 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
TODO.md's Next Step says the remaining 1.0 scope is the owner's decision and that the release mechanism itself is done and exercised (issue #65). Nothing else stands between the tree and a tag except finishing the units in the1.0.0milestone. This issue is the decision.The proposal
Release
v1.0.0when the1.0.0milestone is empty, and the milestone is exactly this:Blockers found in the 1.0 review of issue #119: the
sqlite3binary dependency, the--older-than 6mretention trap, cross-machine restore, CI onnext, and the lint-guard rework. Plus the twelve issues already in the milestone: issue #66, issue #67, issue #68, issue #70, issue #72, issue #73, issue #74, issue #75, issue #87, issue #96, issue #105, issue #112.Explicitly after 1.0 (stays in the README roadmap, no issue): parallel restore downloads,
--bwlimit, restore resume, man pages,snapshot diff, the--cronnotification hook, schema migrations for the shipped index. Also after 1.0 per my recommendation on issue #94: daemon mode.Two items in the milestone are the ones I would drop if the scope must shrink: issue #105 (hash-verifying the release Go toolchain, a policy conformance item that does not change what a user gets) and the fault-injection scenarios in issue #72 beyond corrupt and truncated blobs on read (the two that decide whether restore lies).
What needs you
AGENTS.mdpolicy 13 ("the local index is disposable until 1.0 ships and is tagged") is meant to flip at the tag. If yes, the first post-1.0 issue is a schema-versioning story; if no, the policy text is amended to say the index stays disposable anddatabase deleteis the upgrade path. Issue #68 deliberately does not answer this.merge-ready, mergenexttomainand push thev1.0.0tag; the release workflow does the rest.Model: fable-5-1