You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Support outputting a changelog in reStructuredText #384
It might be related to this PR #376. I don't think we'll explicitly support reStructuredText but make the template customizable instead. This is still under discussion.
I find it a bit hard, because the "magic" is tied to markdown. Commitizen can detect your latest version by reading the titles (#), without affecting extra text nor your old changelog. By doing it this way, you can integrate commitizen into a project with an existing changelog (but only with markdown).
Let's say you didn't generate a changelog for the last 2 releases. What can we do to detect which was the latest release created? We go and read the changelog file.
Let's also say, the last release in the changelog, has been modified by the user. So you cannot replace it.
How do you detect the latest release created, and update the changelog leaving the previous releases untouched?
Because we are tied to markdown, we just compare against any text starting with one or more #, and we insert the incremented missing chunk of changelog, before that.
Also:
We must avoid lines that may contain a mention to the latest release. Example:
# Changelog
Latest release: 1.4.0
## 1.4.0
...
In the end the current solution seemed to be covering our use cases fine so far 😅
If there are better solutions I'd like to know more.
One solution could be to only generate the changelog for the latest release by default. Then, if someone wants to generate a changelog for all releases, have that be a command option. Users should only ever be generating a changelog for more than the most recent version of their project once, at the time of adoption of this tool.
If the user only wanted a changelog for the last X number of versions, then it would be an easy cut/paste job from the command generated changelog. Again, this scenario should only ever happen once in a project's lifetime, so not a big deal.
It doesn't seem you'd need to be inspecting any changelog files with this all or one generation approach, and then could theoretically support any number of file types, given the changelog output itself is configurable.
That makes a lot of sense and would simplify things a lot. Either generate all or latest, right?. If you need specific range you can use cz changelog 0.2.0..0.4.0 and that would cover all the cases. Is a trade-off over more manual work (sometimes), vs making it more flexible to support other formats.
One good thing about the detection of the title is that you can have a bunch of text before the changelog (like the recommendation of keepachangelog before start listing the changes). How could we achieve that?
One good thing about the detection of the title is that you can have a bunch of text before the changelog (like the recommendation of keepachangelog before start listing the changes). How could we achieve that?
A couple of options come to mind, but all require searching the changelog file:
Search for a line with a regex match of the configured release title e.g. v\d\.\d\.\d or something
Use some sort of delineator to split the header from the rest of the changelog like a comment or a dashed line.
Instead of searching for # title for markdown, just include the ability to now search for the header in rst format if in an rst file.
Activity
Lee-W commentedon May 25, 2021
It might be related to this PR #376. I don't think we'll explicitly support reStructuredText but make the template customizable instead. This is still under discussion.
woile commentedon May 25, 2021
I find it a bit hard, because the "magic" is tied to markdown. Commitizen can detect your latest version by reading the titles (
#), without affecting extra text nor your old changelog. By doing it this way, you can integrate commitizen into a project with an existing changelog (but only with markdown).commitizen/commitizen/changelog.py
Lines 181 to 186 in aa0debe
commitizen/commitizen/changelog.py
Lines 221 to 226 in aa0debe
It would involve quite some refactoring unfortunately.
An alternative could be running a markdown to rst as an step in a github action.
jtpavlock commentedon May 25, 2021
Can I ask what the reason for this is as opposed to getting the project version programmatically via package inspection? Is this just a fallback?
woile commentedon May 25, 2021
We can't inspect a markdown file.
Let's say you didn't generate a changelog for the last 2 releases. What can we do to detect which was the latest release created? We go and read the changelog file.
Let's also say, the last release in the changelog, has been modified by the user. So you cannot replace it.
How do you detect the latest release created, and update the changelog leaving the previous releases untouched?
Because we are tied to markdown, we just compare against any text starting with one or more
#, and we insert the incremented missing chunk of changelog, before that.Also:
In the end the current solution seemed to be covering our use cases fine so far 😅
If there are better solutions I'd like to know more.
jtpavlock commentedon Feb 7, 2022
One solution could be to only generate the changelog for the latest release by default. Then, if someone wants to generate a changelog for all releases, have that be a command option. Users should only ever be generating a changelog for more than the most recent version of their project once, at the time of adoption of this tool.
If the user only wanted a changelog for the last X number of versions, then it would be an easy cut/paste job from the command generated changelog. Again, this scenario should only ever happen once in a project's lifetime, so not a big deal.
It doesn't seem you'd need to be inspecting any changelog files with this all or one generation approach, and then could theoretically support any number of file types, given the changelog output itself is configurable.
woile commentedon Jul 27, 2022
That makes a lot of sense and would simplify things a lot. Either generate all or latest, right?. If you need specific range you can use
cz changelog 0.2.0..0.4.0and that would cover all the cases. Is a trade-off over more manual work (sometimes), vs making it more flexible to support other formats.One good thing about the detection of the title is that you can have a bunch of text before the changelog (like the recommendation of keepachangelog before start listing the changes). How could we achieve that?
jtpavlock commentedon Sep 3, 2022
A couple of options come to mind, but all require searching the changelog file:
v\d\.\d\.\dor something# titlefor markdown, just include the ability to now search for the header in rst format if in an rst file.feat(template): allow to override the template from cli, configuratio…
feat(template): allow to override the template from cli, configuratio…
feat(template): allow to override the template from cli, configuratio…
feat(template): allow to override the template from cli, configuratio…
feat(template): allow to override the template from cli, configuratio…
feat(template): allow to override the template from cli, configuratio…
feat(template): allow to override the template from cli, configuratio…
10 remaining items
feat(template): allow to override the template from cli, configuratio…
feat(template): allow to override the template from cli, configuratio…
feat(template): allow to override the template from cli, configuratio…
feat(template): allow to override the template from cli, configuratio…
feat(template): allow to override the template from cli, configuratio…
feat(template): allow to override the template from cli, configuratio…
feat(template): allow to override the template from cli, configuratio…
feat(template): allow to override the template from cli, configuratio…
feat(template): allow to override the template from cli, configuratio…
feat(template): allow to override the template from cli, configuratio…
feat(template): allow to override the template from cli, configuratio…
feat(template): allow to override the template from cli, configuratio…
feat(template): allow to override the template from cli, configuratio…
feat(template): allow to override the template from cli, configuratio…