Repository navigation
chore: release v0.9.38 - #7594
Conversation
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Automations to automatically generate PRs for you. |
There was a problem hiding this comment.
Verdict: REQUEST CHANGES · 1 blocker · 0 important · 0 nits · head 6efd19e6
- blocker — wrong baseline in
releases/v0.9.38.mdand the newdocs/changelog.mdxentry: both were drafted fromv0.9.31instead ofv0.9.37. The "Full changelog" link readscompare/v0.9.31...v0.9.38. Only 9 commits are new sincev0.9.37, andv0.9.37is an ancestor of this head, but the notes list about 60. Most were already announced in 0.9.32–0.9.37. For example, #7573 is inreleases/v0.9.37.mdalready, and #7547, #7511 and #7507 are ancestors ofv0.9.37. The summary sentence ("Many fixes also keep project folders…") describes those older releases. Merging publishes these notes, and the public changelog would list that work twice.draft-changelog.tsgets the baseline fromgit describe. Your local tags v0.9.32–v0.9.37 were probably missing, which its stale-tag check can't detect. To fix: rungit fetch origin --tags --force, then re-runbun run release:prepare 0.9.38, or pass--from v0.9.37.
The version bump itself is fine. All 20 manifests are at 0.9.38 (sdk-playground is private and skipped, as in v0.9.37), the files changed match v0.9.37's release commit, and the branch is one commit on current main.
Scope
I checked the bump in every manifest and compared the release commit's files with v0.9.37's. I checked the notes against git log v0.9.37..HEAD~1 and tested which listed commits are ancestors of v0.9.37. Actions on this head are green; the one red PR-captures run was superseded by a later green run.
6efd19e to
437a8cc
Compare
There was a problem hiding this comment.
APPROVE · 1 resolved, 0 open, 1 new (important) · 6efd19e6 → ef8d5f2a
✅ Resolved: the notes and the changelog entry now start from v0.9.37. They have 9 entries, which match git log v0.9.37..748bfe3b2, and the compare link is v0.9.37...v0.9.38. release:prepare now also reads chore: release vX.Y.Z (#N) commit subjects, so a clone without the release tags can no longer fall back to an older baseline silently. The fails without the fix: test is named.
- important — #7593 is not in the notes:
mainhas moved to32cacab74with #7593 (perf(lint): parse each style block once per lint…). This branch is based on748bfe3b2, so merging ships #7593 in 0.9.38 without listing it. The next draft starts fromv0.9.38and won't pick it up either. It's a perf-only change, so I'm not blocking on it, but rebasing and re-runningrelease:preparebefore merge would add it.
ef8d5f2 to
dffb0a1
Compare
… whose tag this clone lacks
dffb0a1 to
c2fbb30
Compare
There was a problem hiding this comment.
APPROVE · 1 resolved, 0 open, 0 new · ef8d5f2a → c2fbb303. ✅ Recut on main 5a3e46235: the 11 notes entries match git log v0.9.37..5a3e46235 one for one, so #7593 and #7590 are now included. The release:prepare fix is byte-identical to the previous head. Player Safari perf (Heavy films) is not required, and it also fails on main: the 07:26 scheduled run on 32cacab74 failed the same way.
What
Release v0.9.38: version bump,
releases/v0.9.38.md, and the docs changelog. Merging publishes to npm.Why
Ships three fixes people are waiting on: the Studio Volume control changed only the moment under the playhead instead of the whole clip (#7587), a paused video showed darker, richer colors than the same video playing on a Mac (#7584), and edit history entries now carry the layer they touched (#7586). It also carries the other changes on
mainsince v0.9.37 (including the lint speed-up #7593 and the preview-reload fix #7590), and a fix sorelease:preparecannot silently draft from an older release when tags are missing.What people see
No visible change
This PR is the version bump and changelog only. Each change above was captured in its own PR.
Test plan
bun run release:prepare 0.9.38ran on currentmain; the version bump and notes are what it wrote, with the summary written by hand.release:preparerefuse that case: it readschore: release vX.Y.Zcommits in the baseline range and fails when one has no tag here.scripts/draft-changelog.test.tspasses (18 tests); with the v0.9.32 to v0.9.37 tags deleted locally the draft now fails naming them, and with the tags fetched it drafts from v0.9.37. fails without the fix: the newnames a release whose tag this clone never fetchedtest (the old code had no such reader, and the draft silently chose v0.9.31).