Repository navigation
All pre-release changelog on release #817
Description
Hello,
I'm trying to include the commits from the different prereleases in the changelog of the release, but I can't find how to do it.
An idea ?
{{ message }}
Hello,
I'm trying to include the commits from the different prereleases in the changelog of the release, but I can't find how to do it.
An idea ?
Activity
codejedi365 commentedon Jan 25, 2024
An interesting concept, this might be a place for a jinja macro to preprocess the release history object that is passed to the environment of the template renderer and then loop through the resulting object.
I've personally never written a jinja macro but that would be where I would start.
codejedi365 commentedon Jan 28, 2024
After re-reading this, I'm not sure what is your intended outcome for the changelog?
Or
cvalentin-dkt commentedon Feb 1, 2024
What would be interesting is that each "pre-release" has its own change log (as currently).
And when i create the "release", all the previous commits of the different RCs appear in the github changelog.
=> https://github.com/{org}/{repo}/releases/tag/vX.X.X
Actually, just last commit beetwen last RC and release is appear.
codejedi365 commentedon Feb 2, 2024
I think we are talking past each other given the terminology. I was specifically talking about the generation of
CHANGELOG.mdbut it seems you were more interested in the GitHub Release Notes (a per version section of the changes).My understanding is that right now, the release notes are properly generated for each pre-release but you would like to have the newest full tag release to include all of the commits between it and the last full release as if the prereleases never existed. Is this correct?
In other words: At the current moment, only commits between the last prerelease and the new release are posted in the new versions release notes. This is my understanding, yes.
I do not believe this is possible at the current time. I have recently made a fix (#822) which likely will provide this functionality for repos that follow the Git Flow merging strategy. I have not yet tested other strategies and I do not know their outcomes but might be related to making this possible.
ibiscp commentedon Feb 3, 2024
I was hoping to have the same behaviour here, if we generate pre-releases constantly, and after some time we generate a release, the release note is empty, it would make sense to have an option to consolidate all the pre-releases changes in the release.
I believe the rule shoul be:
pre-release- Consolidate all changes since the lastpre-releaseorreleaserelease- Consolidate all changes since the lastreleasecodejedi365 commentedon Feb 4, 2024
@ibiscp, thank you for providing your input
github-actions commentedon Jul 13, 2024
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?
codejedi365 commentedon Jul 13, 2024
Still in the backlog but a valuable improvement nonetheless
11 remaining items
hhaidrr commentedon Mar 8, 2025
@codejedi365 I have the same need for the use-case described here and in (#837).
I briefly read through the issues and read you mentioning that it is actually possible with a macro. Is this still the case? Mind sharing what it is? If not, any idea when this will be a possibility or what my best course of action would be?
I want to only have the changelog and release show changes between full releases, rather than showing them under pre-releases, which ends up causing the full version section to be empty.
codejedi365 commentedon Mar 8, 2025
@Hamzah-Haider, I said it likely would be possible with a jinja macro but it would be complex. I haven't written one to do that but I offered it as a possible intermediate/workaround solution until I had time to correct it in the codebase. Since a jinja macro is essentially code within a jinja template, you would have to write a function that extracts and combines the commit sections of the
context.history.released[PRERELEASE_VERSION]into thecontext.history.released[RELEASE_VERSION]object and then use that resulting dictionary as the input to the templates. You would likely have to apply this macro in theCHANGELOG.md.j2template and the.release_notes.md.j2template where it passes thecommit_objectsobject through the actual formatting component templates. This solution will require you to go through the process of defining custom templates for your project in order to include your new macro.This is one of the higher priority items (that honestly I kinda forgot about as I was solving other valid things) that I need to get to but unfortunately will not have time until at least April/May to complete this as it will not be trivial. My only recommendation to you right now if you don't do the macro above is to adjust the release notes and CHANGELOG after the fact. The CHANGELOG you can do locally
semantic-release version --no-commit --no-tag --skip-buildand then just deactivate--no-changelogduring your actual release activity.hhaidrr commentedon Mar 9, 2025
Thank you @codejedi365 for your detailed and informative response. I really appreciate it.
I will look into the jinja templates with what you have mentioned here and try to hack something out. Otherwise, I will try to see if the CHANGELOG and releases can be modified after the fact by some hack again. I don't really understand the effect of what you described in your last sentence but I will investigate.
If I get something actually working with the jinja macro I can post it here or somewhere for people's reference as a current workaround.
Looking forward to when this is eventually supported. Awesome work!
codejedi365 commentedon Mar 9, 2025
Sorry, clearly I left a lot to interpretation there and it wasn't very clear. What I meant is that essentially you update the changelog manually. It's easy to build or modify a changelog after your PSR release but the corrected changelog is not available on the tag that is defined or in the distribution artifact (which can be confusing to consumers). As I personally would try to get a changelog prior to release, I was explaining how to do that. It would probably take a bit of CI work (if you run PSR via CI) to prevent an automatic release and instead trigger PSR after you have prepared the changelog. To minimize the amount of work you need to do manually, I recommend first using the changelog update mode and then running the version command locally with all the persistent mechanisms off, which results in building the changelog (and stamping the version into your source code). At this point you just need to manually modify the changelog by combining the sections from the pre-releases together. Commit this change and then allow your for your release to execute normally with the changelog generation turned off (
--no-changelogcli option orchangelog: falsefor the GitHub Action).Note that there is also the
changelogsubcommand but it will not create a section for the next release--it only writes a changelog of the current state of the repository. Any new commits will be placed in an Unreleased section. This is still at a point where you can modify the changelog manually but it requires building the version section manually.Good luck!
github-actions commentedon May 9, 2025
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?
codejedi365 commentedon May 13, 2025
Still in backlog
github-actions commentedon Aug 12, 2025
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?
codejedi365 commentedon Oct 3, 2025
No movement yet, still in backlog
Ferdinanddb commentedon Oct 27, 2025
I would also be interested by this feature, as it makes things clearer imho.
github-actions commentedon Jan 26, 2026
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?