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
The audit of rc1 filed one critical finding, fixed in rc2: #387 (prune now keeps unreferenced blobs newer than prune_grace_period; the chosen approach and its one documented gap are on #391).
Open, not fixed for the release candidate: #388 (high), #389 (medium), #390 (low).
Model: opus-5-5
`next` is a release candidate: [`v1.0.0-rc2`](https://git.eeqj.de/sneak/vaultik/src/tag/v1.0.0-rc2).
- The defect hunt (https://git.eeqj.de/sneak/vaultik/issues/288) landed before [`v1.0.0-rc1`](https://git.eeqj.de/sneak/vaultik/src/tag/v1.0.0-rc1).
- The audit of rc1 filed one critical finding, fixed in rc2: https://git.eeqj.de/sneak/vaultik/issues/387 (`prune` now keeps unreferenced blobs newer than `prune_grace_period`; the chosen approach and its one documented gap are on https://git.eeqj.de/sneak/vaultik/pulls/391).
- Open, not fixed for the release candidate: https://git.eeqj.de/sneak/vaultik/issues/388 (high), https://git.eeqj.de/sneak/vaultik/issues/389 (medium), https://git.eeqj.de/sneak/vaultik/issues/390 (low).
Model: opus-5-5
#388: --prune no longer runs after a backup that found a configured path empty, as an unmounted volume's mount point is.
#395: nor after one that did not find a volume an earlier snapshot found mounted below a configured path (found in review of the fix above).
#389: a source host with PUT-only credentials backs up again after its first backup.
#390: prune removes the database a backup left on the destination when its manifest upload failed.
Model: opus-5-5
`next` is a release candidate with no known open bugs: [`v1.0.0-rc3`](https://git.eeqj.de/sneak/vaultik/src/tag/v1.0.0-rc3).
Fixed since [`v1.0.0-rc2`](https://git.eeqj.de/sneak/vaultik/src/tag/v1.0.0-rc2):
- https://git.eeqj.de/sneak/vaultik/issues/388: `--prune` no longer runs after a backup that found a configured path empty, as an unmounted volume's mount point is.
- https://git.eeqj.de/sneak/vaultik/issues/395: nor after one that did not find a volume an earlier snapshot found mounted below a configured path (found in review of the fix above).
- https://git.eeqj.de/sneak/vaultik/issues/389: a source host with PUT-only credentials backs up again after its first backup.
- https://git.eeqj.de/sneak/vaultik/issues/390: `prune` removes the database a backup left on the destination when its manifest upload failed.
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
nextis a release candidate:v1.0.0-rc2.v1.0.0-rc1.prunenow keeps unreferenced blobs newer thanprune_grace_period; the chosen approach and its one documented gap are on #391).Model: opus-5-5
nextis a release candidate with no known open bugs:v1.0.0-rc3.Fixed since
v1.0.0-rc2:--pruneno longer runs after a backup that found a configured path empty, as an unmounted volume's mount point is.pruneremoves the database a backup left on the destination when its manifest upload failed.Model: opus-5-5