feat(release): add breaking changes to release proposal#9196
Conversation
Overall package sizeSelf size: 6.52 MB Dependency sizes| name | version | self size | total size | |------|---------|-----------|------------| | import-in-the-middle | 3.2.0 | 104.26 kB | 843.44 kB | | opentracing | 0.14.7 | 194.81 kB | 194.81 kB | | dc-polyfill | 0.1.11 | 25.74 kB | 25.74 kB |🤖 This report was automatically generated by heaviest-objects-in-the-universe |
🎉 All green!🧪 All tests passed 🎯 Code Coverage (details) 🔗 Commit SHA: 2e313a4 | Docs | Datadog PR Page | Give us feedback! |
BenchmarksBenchmark execution time: 2026-07-02 18:13:49 Comparing candidate commit 2e313a4 in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 2251 metrics, 35 unstable metrics.
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #9196 +/- ##
=======================================
Coverage 93.64% 93.64%
=======================================
Files 898 898
Lines 52365 52365
Branches 12324 12324
=======================================
Hits 49037 49037
Misses 3328 3328 Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 153fd55f11
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
|
||
| for (const pullRequest of pullRequests) { | ||
| const oid = pullRequest.mergeCommit?.oid | ||
| if (!oid || (!isAncestor(oid, `v${releaseLine}.x`) && !isAncestor(oid, upperBoundRef))) continue |
There was a problem hiding this comment.
Include breaking PRs already cherry-picked to the release line
When the pre-release branch is already caught up through earlier proposal runs, allMainShas is empty and upperBoundRef falls back to v${releaseLine}.x; because this script populates release branches with git cherry-pick, the GitHub PR mergeCommit.oid is usually not an ancestor of that branch even though the change is present under a different SHA. This check then filters out those semver-major/only-land-on-next PRs, so the final stable promotion can generate no ### Breaking Changes entries for changes that were already cherry-picked into the release line.
Useful? React with 👍 / 👎.
* add breaking changes to release proposal * fetch from master instead * removes stable path fallback * fix wrong look up
* add breaking changes to release proposal * fetch from master instead * removes stable path fallback * fix wrong look up
* add breaking changes to release proposal * fetch from master instead * removes stable path fallback * fix wrong look up
* add breaking changes to release proposal * fetch from master instead * removes stable path fallback * fix wrong look up
What does this PR do?
Updates the release proposal generation flow to add a
### Breaking Changessection at the top of the release PR description when promoting a pre-release line to stable, such as6.0.0-preto6.0.0.For that promotion path, the script collects merged PRs labeled
semver-majororonly-land-on-next, filters them to PR numbers present in the included release/proposal commit history, and renders them before the regular release notes. This handles release branches built by cherry-picking, where the original GitHub merge commit SHA is not necessarily an ancestor of the release branch.It also de-dupes regular release-note entries when the same PR is already listed as a breaking change.
Motivation
Breaking changes for a new major release are often merged before the release branch proposal is opened, or are guarded/backported in a way that makes
branch-diffunable to identify them reliably.The first stable promotion PR for a new major version should explicitly document those breaking changes, while stable patch/minor release proposals should not include a breaking changes section.
Additional Notes
semver-majorandonly-land-on-nextchanges from normal release notes.Validation:
./node_modules/.bin/mocha "scripts/release/**/*.spec.js"