Manage changelog with towncrier?

[chrysle]

How would this feature be useful?

I think it's time to consider adopting towncrier for keeping the changelog. This would have several advantages, including:

• no merge conflicts due to changelog
• more easily readable, ordered changelog
• ability to describe changes in more detail
• easy changelog creation for contributors and management for developers
  via towncrier CLI

Describe the solution you'd like

Configuring towncrier for this project. I'd be willing to work on that.

Describe alternatives you've considered

I'm not against the current way of managing the changelog.

[uranusjr]

I don’t see why not and would welcome a PR converting the changelog format.

[Gitznik]

I just realized that the current main documentation does not include the latest changelog from 1.4.3. They are in the changelog.md in main, but apparently the docs use the version before the last docs build.
I couldn't find how and when this documentation is updated. Can someone point me the right direction? @chrysle maybe?

[chrysle]

The changelog wasn't built due to the failed job. You can already see it in the latest version. This should be resolved with the next release, I think that's likely to happen soon?

[Gitznik]

Yeah I built it later manually.

But even if it ran successfully - it would just create a new PR for the updated changelog, so it would not be part of the release either way, no? 🤔

[chrysle]

Right, I also thought about that. Maybe it should delete the tag, then recreate it?

[Gitznik]

Probably explains why most other repos have a manual step for creating the changelog: #1201 (comment)

So how it works is that https://pipx.pypa.io/stable/ points to the tag of the latest release?

[chrysle]

So how it works is that https://pipx.pypa.io/stable/ points to the tag of the latest release?

Indeed.

[Gitznik]

If I understand the readthedocs docs correctly, we might just be able to tag the commit after the docs are built with stable, and it should use that over the latest semantic version.

The other option for me would be to manually trigger the docs built when we want to release, and merging that PR would create a GH release. That way the actual up-to-date changelog would also be in the release artifacts.

[chrysle]

If I understand the readthedocs docs correctly, we might just be able to tag the commit after the docs are built with stable, and it should use that over the latest semantic version.

I've created a draft for this suggestion at #1246, please have a look. Also thinking about the second approach.

[chrysle]

FYI the changelog is only included in the sdist, not the built distribution.