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
I have no idea what this issue means. What is the question here? Don't quote random issue numbers at me. Ask me clear questions about what you need from me to proceed.
I have no idea what this issue means. What is the question here? Don't quote random issue numbers at me. Ask me clear questions about what you need from me to proceed.
Sorry, that was unreadable. Plainly: nothing in it blocks work, and nothing is needed from you to proceed.
The fleet finishes the work already planned for 1.0, then hands you the usual next to main merge with a plain description of what it contains.
Whether and when to tag 1.0 stays your call; nobody else tags it.
The one real question in it was whether the local database gets upgraded after 1.0. You answered it on #68 (comment): yes, with migrations after 1.0, and none before.
Handing this back to clawbot.
Model: opus-5-5
Sorry, that was unreadable. Plainly: nothing in it blocks work, and nothing is needed from you to proceed.
- The fleet finishes the work already planned for 1.0, then hands you the usual `next` to `main` merge with a plain description of what it contains.
- Whether and when to tag 1.0 stays your call; nobody else tags it.
- The one real question in it was whether the local database gets upgraded after 1.0. You answered it on https://git.eeqj.de/sneak/vaultik/issues/68#issuecomment-103097: yes, with migrations after 1.0, and none before.
Handing this back to clawbot.
Model: opus-5-5
clawbot
changed title from Decide the 1.0.0 release scope and cut the tag to Work remaining before vaultik 1.02026-09-25 11:38:24 +02:00
sneak
was unassigned by clawbot2026-09-25 11:38:24 +02:00
clawbot
self-assigned this 2026-09-25 11:38:24 +02:00
The 1.0 work is done and on next. It reaches main through #203, which is ready for you to merge; whether and when to tag 1.0 stays yours.
Model: opus-5-5
The 1.0 work is done and on `next`. It reaches `main` through https://git.eeqj.de/sneak/vaultik/pulls/203, which is ready for you to merge; whether and when to tag 1.0 stays yours.
Model: opus-5-5
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
clawbot referenced this issue2026-09-23 13:17:16 +02:00
I have no idea what this issue means. What is the question here? Don't quote random issue numbers at me. Ask me clear questions about what you need from me to proceed.
Sorry, that was unreadable. Plainly: nothing in it blocks work, and nothing is needed from you to proceed.
nexttomainmerge with a plain description of what it contains.Handing this back to clawbot.
Model: opus-5-5
Decide the 1.0.0 release scope and cut the tagto Work remaining before vaultik 1.0The 1.0 work is done and on
next. It reachesmainthrough #203, which is ready for you to merge; whether and when to tag 1.0 stays yours.Model: opus-5-5