Do not accumulate changesets in prerelease mode - #2109
Conversation
🦋 Changeset detectedLatest commit: 43dd604 The changes in this PR will be included in the next version bump. This PR includes changesets to release 16 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2109 +/- ##
==========================================
- Coverage 85.11% 84.95% -0.16%
==========================================
Files 66 66
Lines 2526 2526
Branches 698 696 -2
==========================================
- Hits 2150 2146 -4
- Misses 346 350 +4
Partials 30 30 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
| "@changesets/types": major | ||
| --- | ||
|
|
||
| When exiting prerelease mode, the final changelog will now not include all changesets made since `pre enter`. This change was made as often changes during prereleases are not relevant to the final release, and it's not possible to query the entire Git and GitHub metadata when the backlog of changesets become sufficiently large. |
There was a problem hiding this comment.
how are we going to help with changeset pre exit then?
There was a problem hiding this comment.
I don't quite understand the question. You mean how should the exited/stable release changelog should be? They could add changesets that summarizes the changes if they like just before the stable is released.
There was a problem hiding this comment.
- Re-adding changesets will screw up commit/PR auto-references generated by our changelog generators.
- It feels to me that we have many more meaningful changesets aggregated during pre mode than the temporary ones. So it feels that cleaning up temporary ones is less of a chore that having to re-add what is still relevant
There was a problem hiding this comment.
i don't think we should remove the accumulating changesets.
while it does suck when it has been open a long time i also don't think a lot of people are prepared to re-add changesets when exiting pre-release mode, at least not now.
maybe an option for this behavior would be better?
There was a problem hiding this comment.
- I don't think it matters a lot but we can probably explore/expand on "none" changeset types that are added only for adding changelog, and we'd not link the commit/PR for it. They can also write a summary that links to the right PRs.
- Well there's a tipping point in which adding vs removing becomes a chore or not, depending on the size, like Exiting pre mode fails with 400+ changesets #1688. But fundamentally for me, it's better to keep changesets as summaries that describes the next version. Lending it to also describe the stable version doesn't feel right by default.
There was a problem hiding this comment.
while it does suck when it has been open a long time i also don't think a lot of people are prepared to re-add changesets when exiting pre-release mode, at least not now.
They don't have to add a changeset when exiting. If there's not many prereleases, users can also read through the changes that happen before instead of duplicating it. If they don't have the habit of making the changelog good anyways then it's better we don't generate potentially low quality changelogs either.
maybe an option for this behavior would be better?
I prefer to not make an option for now. It also keeps our handling simpler.
There was a problem hiding this comment.
They don't have to add a changeset when exiting. If there's not many prereleases, users can also read through the changes that happen before instead of duplicating it. If they don't have the habit of making the changelog good anyways then it's better we don't generate potentially low quality changelogs either.
This strategy doesn't quite work for GitHub releases that are derived from the latest CHANGELOG.md version entry.
There was a problem hiding this comment.
I don't think it doesn't work, they'd have to look for the changes themselves elsewhere from the UI and that's an ok tradeoff.
close #1688
close #240
fix #1050
No tracking of changesets in
pre.json, and clear changesets during version in prerelease like normal. The final pre exit release will not contain changelog of all previous prerelease changelog.I'm still thinking whether to handle
pre.json"changesets" still (filtering) so it's more compatible, but in this PR I took the more drastic approach for now and remove it entirely, and rely onreadPreStateto automatically apply the migration. The migration is mainly for those migrating from v2 while still in prerelease mode.Any calls to
readPreStatewill delete the"changesets"property and its referenced changeset files. This may be a little surprising.