Unexpected & undesriable CHANGELOG results when prerelease then release

The problem

I have two CI/CD jobs: one for prerelease that is executed on branches != main and one for (final) release, which is executed when merging to main.

If you create a prerelease from a branch, CHANGELOG.md will be updated, creating a new section with the prerelease version (e.g. x.x.xrc1)

Then, when the release is created, a new section is created for it in the CHANGELOG (e.g. x.x.x), but this section is empty.

Either I'm doing something wrong or the CHANGELOG interaction when prereleasing wasn't taken into account.

Expected

The optimal would be deleting the prerelease section in the CHANGELOG and creating a new section for the release with the changes made since the last release on it.

Library Version

Latest version

Hey 👋
Which commands are you running on each branch, and what does your configuration look like? Is it the same configuraiton for each?

@bernardcooke53

@bernardcooke53

prerelease: semantic-release publish --prerelease -D branch=$CI_COMMIT_BRANCH -D prerelease_tag=rc
release: semantic-release publish -D prerelease_tag=rc
release conf (only for release not prerelease):

hvcs = "gitlab"
upload_to_repository = true
build_command = "pip install poetry && poetry build"

@bernardcooke53

@bernardcooke53 any updates on this?

@claverru

@claverru finally had a chance to roll back round to this - I don't think there's a way to avoid this in v7, because of the way new content is inserted to the changelog - once you merge the commits from a branch to main, they're "already released" in the prerelease version, so there's nothing "new" to add under the release you then create from main. I think that's desired behaviour anyway - there's no change over the prerelease version.

I think I get what you're after, though - some way to aggregate all the changelog entries into the section under the release, eliminating the entries for the prereleases. You should be able to do this with a template in v8, although if you squash and merge the branch then the changelog will be regenerated with just that merge commit under the new version on main

@bernardcooke53

I realized this was intended when I read your release notes here in github. It's just weird that, and the end of the day, I have only notes on prereleases but not on releases, because every mapping change (fix, feat, etc) is first built as a prerelease.

I will have a look to these templates, didn't have the chance to investigate what they are for.

Also, thank you so much for answering me in every issue @bernardcooke53 . I feel like spamming.

@claverru

It's a bit of a strange one to adjust to - definitely in v7 we're a bit pinned down to just extracting the information from the commits, we can't/don't regenerate the changelog entirely.

I noticed a pretty significant trend with PRs along the lines of "allow x customisation in changelogs, add x config setting and an if config.get(x) statement", which is a pretty slow cycle and adds up to messy/competing logic over time. Introducing templating means you don't need to go through any of that to adjust the changelog, you can do it in your own project

Template-wise, my idea here would be to render the headings only if the version isn't a prerelease version, so the commits would only appear under the release version.

I'm expecting over time there might be some feature requests for new pieces of context to enable bits of customisation, but honestly you can get pretty far with what's already there (in my opinion, biased for sure).

Spam away @claverru - I try and get back to issues as soon as I reasonably can, and if you weren't asking the questions I'm sure someone else would sooner or later. Really appreciate all the feedback and time you've put into figuring things out too 🏅

I'd be interested in this feature too - if doing it in templates is the correct way to do it, could we have a demo?

I do worry that there could be git merge histories where it could result in a commit being in the wrong release - e.g.

graph TB
  A["v1.0.0"] ----> B["v1.0.1"]
  A --> C["v1.0.1-rc1"]
  B --> D["v1.0.2"]
  C ----> D

How do we ensure that the features that appear in v1.0.1-rc1 are listed in v1.0.2 not v1.0.1?

@cc-stjm

@cc-stjm, are you also using v7?

I'm working on a lot of changes related to the changelogs although it has recently come to my attention with #789, you may be experiencing issues due to an algorithm bug.

I hope to finish these updates in the next few weeks and I will see if I can address this in my efforts.

I was using python-semantic-release 8.7.0

@codejedi365

@codejedi365 you mentioned you were looking at some updates in this area, did you finish that work?

It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?

No update, still in backlog

It has been 90 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?

Still in backlog

It has been 90 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?

Navigation Menu

Repository navigation

Unexpected & undesriable CHANGELOG results when prerelease then release #555

The problem

Expected

Library Version

32 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Unexpected & undesriable CHANGELOG results when prerelease then release #555

Description

The problem

Expected

Library Version

Activity

bernardcooke53 commented on Feb 17, 2023

claverru commented on Feb 20, 2023

claverru commented on Jun 13, 2023

bernardcooke53 commented on Jun 22, 2023

claverru commented on Jun 26, 2023

bernardcooke53 commented on Jun 27, 2023

cc-stjm commented on Jan 9, 2024

codejedi365 commented on Jan 11, 2024

cc-stjm commented on Jan 11, 2024

cc-stjm commented on Apr 11, 2024

32 remaining items

github-actions commented on Jun 17, 2025

codejedi365 commented on Jun 18, 2025

github-actions commented on Sep 17, 2025

codejedi365 commented on Sep 23, 2025

github-actions commented on Dec 23, 2025

github-actions commented on Jul 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions