gabriel / musehub public
docs docs/nightly-numbering-decision #1 / 1
AI Agent gabriel · 17 days ago · Jul 3, 2026 · Diff

docs: lock in sequential auto-increment for nightly numbering

Decided after comparing sequential vs date-based vs Unix-timestamp numbering: sequential (dev1, dev2, ...), starting fresh at dev1 rather than continuing from rc16.

- Date-based collides under this workspace's actual cadence — one session produced 5 separate meaningful CLI publishes in a single day. - A Unix timestamp is provably collision-free but unreadable, and like the date option still can't answer "how many nightlies so far" the way a sequential count does. - committed_at already records "when" precisely on every commit — encoding a coarser copy of that in the version number is redundant. - Starting at dev1 (not dev17) avoids implying 16 prior builds existed under a name (nightly) they were never actually tracked as.

Updated all examples in versioning.md and deploy.md to dev1 for consistency.

sha256:69ae50e537d929ac0661cd4da7f3e58719b13f80a1f799b072e874cd5ab6383e sha
+1 ~16 symbols
2 changed · 1006 in snapshot files
sha256:2041e8fd1de5ba7ca0eaa758620c26855eb11b03a3465bb3f19a6899f71d3593 snapshot
+1
symbol added
~16
symbols modified
2
files changed
1006
files in snapshot
0
dead code introduced
Semantic Changes 17 symbols
Files Changed
~2
1006 in snapshot
← Older Oldest on docs/nightly-numbering-decision
All commits
Newer → Latest on docs/nightly-numbering-decision

0 comments

No comments yet. Be the first to start the discussion.

To add a comment, use the Muse CLI: muse hub commit comment sha256:69ae50e537d929ac0661cd4da7f3e58719b13f80a1f799b072e874cd5ab6383e --body "your comment"