docs: clarify when changesets and server-changes files are needed - #4617
Conversation
|
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (1)
📜 Recent review details🧰 Additional context used🪛 LanguageTool.claude/rules/server-apps.md[grammar] ~8-~8: Ensure spelling is correct (QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1) 🔇 Additional comments (2)
WalkthroughUpdated release-note guidance across repository documentation. User-facing package changes require changesets. User-facing server-only changes require 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
f7fbf45 to
6cebbff
Compare
6cebbff to
0adb150
Compare
0adb150 to
7a878e5
Compare
Reframe changesets and .server-changes notes as user-facing release notes rather than a catalog of every change. The test is whether a user or customer would care, not whether a public package or server app was touched. Call out the skip cases: internal/admin-only changes, refactors, chores, performance tuning with no user-visible effect, and public packages that are not consumed independently.
7a878e5 to
32d2f02
Compare
Summary
Clarifies when to add a changeset or a
.server-changes/file. The friction that keeps coming up is treating these as "I touched a public package or a server app, so I owe a note." They are user-facing release notes that go straight into the changelog customers read, not a catalog of every change.The guidance now leads with the real test: would a user or customer care about this change? Add a note when the change is something they would notice, act on, or want to hear about. Skip it otherwise, even when a public package or server app is touched, for example:
@trigger.dev/redis-worker), where a version bump means nothing to a userAnyone who wants the exact history reads the commits.
Updates every place that encoded the old "touched a package or app, so add a note" rule so they agree:
AGENTS.md,.server-changes/README.md,CONTRIBUTING.md,CHANGESETS.md,.claude/rules/server-apps.md, and.claude/REVIEW.md(the last drives automated review flagging, so it stops flagging exactly the changes the new guidance says to skip). Also handles the mixed-PR case where the package change needs no changeset but the server change is user-facing.