I would like to start using
towncrier for managing the
CHANGES.rst file in several Plone packages. This tool gathers news fragments from a directory, instead of relying on developers keeping the
CHANGES.rst file up to date. Editing a changelog file doesn’t sound too hard, but usually in the end it is not a developer that does this, but github. And I have seen this go wrong too many times:
- You create a pull request for a bug fix in version 1.0.
- Someone creates a release 2.0 without your fix.
- Your fix gets reviewed and merged.
- Problem: after the merge, your fix is likely mentioned under the 1.0 version header. (See for example this commit to fix such an error.)
- Or: some extra, completely unrelated lines get merged into the changelog.
- If this doesn’t get caught before release, it takes a software archeologist to figure out in which version a fix was really done.
To avoid problems like this, the pip project has been using
towncrier for about a year now. The pip documentation explains how to use it. Basically, in a PR you would create a
news/1234.bugfix file or a
news/42.feature file. You do not touch
CHANGES.rst. At release time, the person doing the release calls
towncrier, which handles updating
CHANGES.rst and removing the news fragments.
I (and the Plone Release Team) want to start using this for Plone packages as well. It may not be useful for all packages. The most to be gained would be for packages that get lots of changes, or that have multiple active branches. Likely we would start with just a couple of packages, like Products.CMFPlone and plone.app.upgrade, to see how it goes.
Some work is on the way, like creating a zest.releaser plugin (see https://github.com/collective/zestreleaser.towncrier/issues/1) and a couple more things need to be done, like updates to
mr.roboto (see https://github.com/plone/plone.releaser/issues/17).
But I would like some feedback. Do others see the need of this as well? Maybe you have used towncrier already in other projects?