Skip changelog entry in defined branches

[mtrezza]

Issue

Consider this scenario:

1. In pre-release branch alpha a commit is merged for a feature with commit message feat: a.
2. Before a beta or stable release is created, a bug is discovered in the feature.
3. In alpha branch, a fix is merged with commit message fix: a not working.
4. The pre-release branch is merged into the beta and later stable release branches.

The created changelogs for beta and stable release contain both entries, for feat and fix. However, outside of the alpha branch, the fix is irrelevant in the changelogs.

A fix in the beta changelog means something has been fixed relative to the previous beta release. Same goes for the stable release changelog. But that is actually not the case. So not only is the fix changelog entry incorrect, it is also confusing for readers as nothing has been fixed relative to the previous release.

Solution

Add a flag to the commit message to skip the entry into the changelog of a specific branch.

In the above example the fix commit message could look like this:

fix: a not working [skip-changelog-beta] [skip-changelog-stable]

Additionally, an inverse flag could be introduced to specific the branches for which the commit should produce a changelog entry:

fix: a not working [only-changelog-alpha]

[tomerh2001]

Also introducing "channels" / "branches" configurations would be very helpful.
i.e.

  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    "@semantic-release/npm",
    ["@semantic-release/changelog", {
       "branches": ["main"]
    }],
    "@semantic-release/git"
  ]

Would only update the changelog when publishing from the branch main

[travi]

our stance on pre-releases is that release notes are just as valuable in that context as they are in stable release channels. we do not intend to take steps to prevent release notes from being published in pre-release channels, or make it more complex than it already is to post them.

we recognize that this does leave the situation where a fix might be relative to the pre-release channel and not its relation to the stable release (or more stable pre-releases), but the nuanced situations that arise in those scenarios are too difficult to attempt to resolve automatically, even if we were to introduce more complexity as described here. instead, our recommendation is simply to manually edit the published release notes after promoting a release. we understand that deviates from the goal of being fully automated, but we think this is the best middle ground available

[tomerh2001]

@travi I don't understand, it's not like we're talking about changing the entire project, why can't you just add it even tho you don't support it? I'll create the PR if you want.

Why not make your tool versatile, instead of locking it into an opinionated state.

Look how my changelog looks now after starting to use alpha and beta channels:

2.15.0 (2025-02-25)

Bug Fixes

• add missing newline at end of package.json and refactor Otp2 component structure (16f3731)
• update OTP flow and remove login route (72c70ef)
• introduced beta and alpha release channels (f35cf60)

2.15.0-beta.1 (2025-02-25)

Bug Fixes

• add missing newline at end of package.json and refactor Otp2 component structure (16f3731)
• update OTP flow and remove login route (72c70ef)
• introduced beta and alpha release channels (f35cf60)

2.15.0-717.2 (2025-02-24)

Bug Fixes

• add missing newline at end of package.json and refactor Otp2 component structure (16f3731)
• update OTP flow and remove login route (72c70ef)

2.15.0-717.1 (2025-02-24)

Bug Fixes

• introduced beta and alpha release channels (f35cf60)

Why do I need all of that verbosity? I only want v2.15.0's release in the changelog, the rest is just redundant junk that's repeating the same thing again and again.

If that's how you want your changelog than sure go for it, but what's the harm in adding a branch/channel filter so that the user can have more control? IMO that's toxic maintenance for the project. I very much hope you guys would reconsider this small and meaningful feature, as my usage of semantic release is resting on this - if you can't support it, then I'll be forced to move to a more reliable automated semver, unfortunately :/

Again, I'm willing to offer that I'll implement the changes, you guys just need to accept it.

[travi]

even tho you don't support it?

this is the simple answer. we dont support it. we are a small team of volunteer maintainers. semantic-release is an opinionated project. we do not support gitflow, which is the workflow where the sort of request most often originates. we have to consider long term maintenance of every feature we accept to the project, not just the cost of initial implementation. we believe that including release notes with all releases is the best practice when using our supported workflows and the cost of making that optional is too high for our team at this time.

Why do I need all of that verbosity? I only want v2.15.0's release in the changelog, the rest is just redundant junk that's repeating the same thing again and again.

what makes it redundant? do you have real people consuming your pre-releases? if so, why are the release notes not valuable to them before the stable release is available?

also, on the topic of being redundant, are you aware that we recommend against using this plugin in the first place in most cases? if you are also publishing release notes to github releases (default behavior), or similar, having a changelog file at all is redundant and far more complex since you then need to make it possible to push the commit back to your repo

• https://github.com/semantic-release/changelog#semantic-releasechangelog
• https://semantic-release.gitbook.io/semantic-release/support/faq#should-release-notes-be-committed-to-a-changelog.md-in-my-repository-during-a-release

then I'll be forced to move to a more reliable automated semver

we recognize that being opinionated does mean that we dont fit everyone's workflow. we would rather you use a tool that works well for your goals, even if that is not semantic-release