For example, if my changelog contains entries for 1.0.0-alpha.1 and 1.0.0-beta.1, I would like the eventual 1.0.0 release notes to include the changes introduced by those pre-releases.
Separately, some projects may want the final release to supersede its pre-release entries entirely: when 1.0.0 is released, the 1.0.0-alpha.* and 1.0.0-beta.* entries would be removed and their changes amalgamated into the 1.0.0 entry.
I think these are two related but distinct behaviours:
-
Copy pre-release changes into the final release
When preparing a final release, include changes from previous pre-releases of the version.
For example:
### 1.0.0
A, B, C, D, E
### 1.0.0-beta.1
C
### 1.0.0-alpha.1
A, B
-
Collapse the pre-release entries into the final release
As an alternative, remove the previous pre-release entries when creating the final release, leaving a single 1.0.0 entry containing all of their changes. For example:
I believe there are valid use cases for both retaining the pre-release history and amalgamating it, so these should be separate options or different modes of an option.
Implementation considerations
One complication is that PrepareRelease currently consumes changeset files when preparing a release. For a pre-release, those changes therefore aren't directly available when the eventual final release is prepared.
One possible solution would be to retain changesets that have been included in a pre-release, but move them into a separate directory (for example .changeset/pre/). They would then be excluded from subsequent pre-releases but included when preparing the final release.
This would also allow those changesets to be edited or removed before the final release if the corresponding change is no longer relevant.
Another possibility would be to derive this information from the existing pre-release changelog entries/tags instead, so that pre-release changeset files do not need to be retained.
The important distinction is that changes already included in an earlier pre-release should not be re-included in subsequent pre-releases; they should only be carried forward to the eventual final release.
The JetBrains Changelog Gradle plugin has similar behaviour: when creating the final version section it also includes changes from previous pre-release sections of that version. Its current implementation also applies this behaviour when creating further pre-releases, which is one aspect I'd like to avoid.
For example, if my changelog contains entries for
1.0.0-alpha.1and1.0.0-beta.1, I would like the eventual1.0.0release notes to include the changes introduced by those pre-releases.Separately, some projects may want the final release to supersede its pre-release entries entirely: when
1.0.0is released, the1.0.0-alpha.*and1.0.0-beta.*entries would be removed and their changes amalgamated into the1.0.0entry.I think these are two related but distinct behaviours:
Copy pre-release changes into the final release
When preparing a final release, include changes from previous pre-releases of the version.
For example:
Collapse the pre-release entries into the final release
As an alternative, remove the previous pre-release entries when creating the final release, leaving a single
1.0.0entry containing all of their changes. For example:### 1.0.0 A, B, C, D, EI believe there are valid use cases for both retaining the pre-release history and amalgamating it, so these should be separate options or different modes of an option.
Implementation considerations
One complication is that
PrepareReleasecurrently consumes changeset files when preparing a release. For a pre-release, those changes therefore aren't directly available when the eventual final release is prepared.One possible solution would be to retain changesets that have been included in a pre-release, but move them into a separate directory (for example
.changeset/pre/). They would then be excluded from subsequent pre-releases but included when preparing the final release.This would also allow those changesets to be edited or removed before the final release if the corresponding change is no longer relevant.
Another possibility would be to derive this information from the existing pre-release changelog entries/tags instead, so that pre-release changeset files do not need to be retained.
The important distinction is that changes already included in an earlier pre-release should not be re-included in subsequent pre-releases; they should only be carried forward to the eventual final release.
The JetBrains Changelog Gradle plugin has similar behaviour: when creating the final version section it also includes changes from previous pre-release sections of that version. Its current implementation also applies this behaviour when creating further pre-releases, which is one aspect I'd like to avoid.