I’ve written a tool for managing changelog files, called scriv. It focuses on a simple workflow, but with lots of flexibility.
I’ve long felt that it’s enormously beneficial for engineers to write about what they do, not only so that other people can understand it, but to help the engineers themselves understand it. Writing about a thing gives you another perspective on it, your own code included.
The philosophy behind scriv, and a quick list of other similar tools, is on the Philosophy page in the docs.
Scriv only does a few things now, but I’m interested to hear about other changelog workflows that could use better tooling.
Comments
My workflow, when it's fully automated it's a miksture of bumpversion and towncrier, and both tools had to be a bit modified for that:
What I need usually is to:
1) Determine new version, either stable or dev version (based on git describe) (bumpversion part)
2) Generate changelog for that new version. (towncrier)
3) If it's stable, commit, git tag, push to master and merge to dev. (bumpversion part)
For half automated I write changelogs manually (personal OS projects), although I'm planning (that's the good word) to migrate to some automation changelog tool.
Oh, and where possible I'm trying to embed the tool inside a docker image, mount the code there. This makes the commit and tag part hard to do locally, but a breeze on the CI.
Add a comment: