Repository navigation
Tag v0.1.0 and the release flow #6
Description
What. Cut Frame's first tag after #5, under the fleet release workflow: trunk-based main, a tag pushed on a green commit, change files. Document how consumers pin Frame (git + tag) and the [patch] tables they must repeat. Add a cargo xtask fleet-bump entry so Frame moves with the fleet's architect bumps.
Why. Studio (FastTrackStudios/studio#373) and Signal depend on a tag, not on a path or a branch.
Done when.
- tag
v0.1.0(or the fleet's CalVer, per Cody) on a greenmain - a consumer snippet in the README, checked by a tiny out-of-tree crate in CI that builds against the tag
Related. #2, #5, FastTrackStudios/studio#373
Plan: frame-designer-plan.md in Cody's planning folder (/run/media/Development/wt/.architect-issues/, THEBATTLESHIP), section "Consolidation: all of Frame in FastTrackStudios/frame; Studio depends on it by tag".
Filed by bship-frame-plan (Claude Code) from the Frame designer plan. Not claimed.
Activity
fts-forge commentedon Nov 2, 2026
Proposed: tag
v0.1.0ond37d905, the merge of #29. Itsmainrun is green: Check, Lint (fmt + clippy + boundary), Consumer andci.Not tagged yet; that waits on your go-ahead. After the tag:
examples/consumerbuilt in CI,just fleet-bump vX.Y.Z ../framefrom architect);tag = "v0.1.0"once studio#372 lands.Command, as the user:
git tag -a v0.1.0 d37d905 -m "frame v0.1.0" && git push origin v0.1.0.fts-forge commentedon Nov 2, 2026
Tagged v0.2.0 on d37d905 (main, CI green). v0.1.0 already existed (2026-09-29, on 06cdaeb), and tags are never moved. Studio's switch (studio#373) pins v0.2.0.