Comparison between towncrier and OpenStack reno?

[hartwork]

Hi!

This tool seems to be similar to OpenStack reno? Maybe a quick paragraph in the readme comparing towncrier to other existing tools would be great to have.

Thanks!

[adiroiban]

I wasn't aware of reno.

I am living in the Twisted bubble since 2011.

Happy to hear there are alternatives.

I think it would help to mention reno on the front page of Towncrier,
not necesarily for a comparison, but for other people to be aware of reno
They can check reno and make their own comparison.

Just some quick notes.

I think towncrier has a more relaxed format for the fragment files.
You don't have to worry about YAML.
It's just text that you can use in jinja.

And in reno, I don't see the option to customize the final release notes.
In towncrier, you just have a jinja template ... for the better or the worst :)

I have checked the code for reno, and I don't see any template used - https://opendev.org/openstack/reno/src/commit/aae5632aa19242bdd5e5abc2d919cdcb0b1b9e15/reno/formatter.py#L44

[adiroiban]

@hartwork do you use towncrier or reno or both ?

Can you leave a comment here with what you think should be included in the comparison?

I am not keen to do the comparison, as it can be subjective.

But if we have 2 people providing content for this doc, it might end up less subjective.

Anyway, mentioning reno is a thing that we should do

[hartwork]

Hi @adiroiban,

I have been using reno on one past non-public project, but not sence then.

After playing with towncrier and reno a bit just now, some things I noticed are:

• towncrier seems to want to delete news fragment files and keep the combined result in Git while with reno it seems that fragment files remain in Git "forever" and the combined result is not in Git at all.
• towncrier seems more focused on issue and pull request references than reno (and that seems to have consequences), e.g. towncrier seems to support empty entries — plain issue/PR references — that would probably be alien with reno.
• towncrier can seemingly be made to produce markdown (demo) while reno seems limited to rst; that markdown option is nice for people who consider nesting in rst fundamentally broken.
• towncrier uses multiple files for what reno uses YAML for.
• towncrier seems to not inspect Git history much and add to NEWS.rst if existing while reno uses Git history more and always overwrites everything. That's a key difference.
• towncrier seems to support any kind of git workflow while reno only supports a model with a single active main branch.
• (towncrier says ${project} ${version} in the output repeatedly by default while reno goes with ${version} only)

@adiroiban does that sound fair and realistic towards towncrier? I'd be curious about your view, no worries about bias.

[altendky]

I've only read about reno but everything you point out seems valid. A few of your points relate to this, but I think it's worth pointing out directly that with reno you can retroactively define a release commit whereas with towncrier it is generally expected that you will create a commit of the changelog in preparation for the release. This ties to reno keeping only the newsfragment sources in the repo while towncrier keeps the generated result in the repo. Both have upsides certainly.

[adiroiban]

Thanks!
I have never used reno so, I can't judge.

But the info over here looks valid and I think can be used as a source for a future documentation update.