Make whitespace between releases configurable
iliakur opened this issue · comments
Status Quo
towncrier build will generate the following example changelog entry
<!-- towncrier release notes start -->
## <New Release>
### Changed
- Something changed
## Old Release
Notice how there are 2 newlines between Something changed and ## Old Release.
It may be useful in some contexts to customize it. For instance I'm on a team that prefers not to have the second newline between releases.
I think the most flexible solution would be to add a configuration field called something like release_separator. It could have a default value of either \n or \n\n depending on what we consider as an integral part of one release section.
I think that this can be configured by providing a custom Jinja2 template.
Would that work for you?
Cheers
I tried removing all kinds of whitespace from this template with no success:
{% if sections[""] %}
{% for category, val in definitions.items() if category in sections[""] %}
***{{ definitions[category]['name'] }}***:
{% for text, values in sections[""][category].items() %}
* {{ text }} {{ values|join(', ') }}
{% endfor %}
{% endfor %}
{% else %}
No significant changes.
{% endif %}
lmk if you need any more setup from me to repro this.
I guess that this is an of Jinja whitespace control.
https://jinja.palletsprojects.com/en/3.1.x/templates/#whitespace-control
Just a very quick and brief suggestion.
Have you tried something like ?
{% if sections[""] -%}
{%- for category, val in definitions.items() if category in sections[""] %}
It's a good call with the jinja whitespace control, I forgot about that.
After trying to remove all possible whitespace in the jinja template without success, I dove into the towncrier code and I think this line is the culprit.
No matter what my template looks like, there are always 2 newlines inserted before the previous releases...
I don't really know of a backwards-compatible way to solve this without exposing a config variable and setting it to \n\n by default.
wdyt?
Thanks for looking into this.
Would it work if the hardcoded newlines are removed from the code and the default template is updated to compensate for that?
If we somehow could get full functionality via the template, I would prefer that, over adding many configuratin flags.
But if this is big issue for you and submit a PR with a new configuration option that is well documented and tested, I would not reject it.
I would prefer to have the core towncrier writer just write fragments, without doing any extra formating.
The full formating be done via templates + other configuration options like the issue template.
I would also much prefer to move this type of thing into the template. I'm just worried that for anyone who's not using the default template this will be a breaking change.
If you think that's ok, then I can make a PR that moves the whitespace into the default template. Otherwise I could make a PR with the extra config field.
I think this is ok.
My understanding is that most people are using towncrier as a dev tool, and not as a production / user facing tool.
developmenent time for towncrier is limited and is done as a hobby.
so, to simplify the configuration file, I think is best to make this change in the template.
we can add a note in the release note instructing anyone using custom templates to double check their templates.
and if anyone is anoyed by the change, they can try to look over the development of towncrier and help with pre-release feedback.
Also, I am not sure how often people update towncrier in their environments.
I have a release from 2017 that works for me, and I don't see the need to upgrade :)
It just works... so why bother spending extra time with an upgrade without getting anything back :p
so it's your call :)
I'm ok with any option.
the purpose of towncrier is to be useful to developers.
so if any change is useful for you, I am ok with that.
Thanks for the feedback.
Sounds good, I'll go ahead and make the PR where I move the newlines into the default template!
@adiroiban PR is up!