Adopt a changelog manager

[jaraco]

skeleton-based projects (except for Setuptools and maybe cherrypy libs) currently rely on manually-merged CHANGES.rst, meaning it's not feasible for changes in the skeleton like 133c5e6 to generate changelog entries when incorporated in projects downstream. Adding a manual entry there would cause conflicts with every merge downstream.

The solution for this problem is for projects to adopt something like towncrier or scriv or reno. My main reluctance in adopting one of these is that they all require an extra "finalization" step prior to cutting a release. The current process is super-lightweight (tag and push). Adding a changelog manager will require that every release be managed and managed on a device that has a terminal and git push access. It's conceivable that a Github action could be added to enact a finalize step.

I'm also somewhat reluctant as I'd like to avoid the need to create a new file for each change, but the only alternative would be to somehow indicate the user-facing release notes in the commit history, and since no project has successfully demonstrated that, I'm inclined to accept the file-based approach, despite the toil that adds.

Another concern I want to address is to avoid the need for there to be an issue associated with every change. Although it's best practice to associate an issue or PR with a change, I don't want to require that there be one, the way the Setuptools project does. I want a process that degrades nicely for projects that are informal and fast moving.

I wanted to use reno, as it promises not to require a 'finalization' step, but the caveats scare me. My next instinct would be to use scriv, but since Setuptools uses towncrier, it may be best to use towncrier.

[jaraco]

I looked briefly into reno, but it's definitely not able to support git-flow workflows. I tested it out and confirmed that if one merges a bugfix into main, the release notes for that bugfix only appear in the bugfix release and not in subsequent releases, so it's a poor fit for the projects I maintain.

I looked next into towncrier, whose docs indicate that the configuration requires per-project customization.

However, I found through testing that the package key isn't required, so the minimal config appears to be simply having a towncrier.toml file with a [tool.towncrier] header, so that may be suitable.

[jaraco]

One of the things that needs to happen with each release is (a) determine the last released version on the branch, (b) calculate what bump to apply based on the pending "newsfragments", (c) apply that bump to the last released version, (d) generate the changelog for that version, (e) commit that change, and finally, (f) tag the commit.

Best I can tell, none of setuptools_scm, bump2version, towncrier, or any other tool can help with anything but (d). In Setuptools, I rely on a finalize script, but that relies on bump2version and the fact that version numbers are hard-coded in files, a downgrade from the setuptools_scm workflow.

[jaraco]

I'm reminded that I've done some of this work before:

pip-run hgtools -- -c "from hgtools import managers; print(managers.RepoManager.get_first_valid_manager().get_next_version(increment='0.1'))"
24.1