Changelog handling in semantic-release?

Question

Using semantic-release in our Github workflows.

They are setup like this:

[
  {name: 'main', prerelease: false},
  {name: 'staging', prerelease: true},
  {name: 'development', prerelease: true}
]

Pushes to development are deployed to development environment, staging to staging etc.

Now with the package above every time the version is bumped, semantic-release creates a changelog using semantic-release/changelog.

How should we handle the conflicting changelogs in the different branches now?

1. Option: Only enable changelog creation on release branches. (I don't know how. Plugin has no such option.)
2. Option: Automatically merge back the changelog into the 'hierarchically' lower branch. E.g. staging back into development.

I am wondering is there anyone out there with a similar problem?

Paleolith

Answer 1

Since I see people upvoting this question. I opened a PR with semantic-release/changelog to allow the use of templating in the CHANGELOG.md filename. This way at least you could have different changelogs for different branches. There has been 0 activity from the maintainers though. Soon its gonna be open for a year...

Here is the PR: https://github.com/semantic-release/changelog/pull/106.

Paleolith

github.com/semantic-release/changelog/pull/…: "This branch is out-of-date with the base branch": Don't forget to rebase your PR branch on top of upstream(semantic-release)/master, and force push your PR branch again. – Imre

@VonC, yeah not gonna do anything until a contributor makes a comment in the PR. Otherwise I'll be rebasing for the next year. – Scrubber