Include semver impact in changelog entries and derive next version from that

[thomaseizinger]

trafficstars

I am trying to define an automation-friendly versioning and changelog management strategy for rust-libp2p (see https://github.com/libp2p/rust-libp2p/issues/2902). It is a workspace with 33 crates which makes things rather involved.

One of the core problems is that we want to capture the semver impact of a change at PR creation time. Currently, we do this by bumping the version in the PR which is annoying for the author and prone to merge conflicts if two PRs make breaking changes at the same time.

I came up with an idea very similar to what you have been building here with one addition: I was going to track the semver impact of a change as metadata in the entry as well. Something like:

---
type: Misc
subject: Initial Implementation
breaking: true
---

Then, at release time, you go through all unreleased changes and based on the current crate version + breaking, infer what the next version is:

• No breaking changes and current version is 0.5.0? Next version is 0.5.1
• No breaking changes and no changes with type: Feat and current version is 1.5.3? Next version is 1.6.0.

What do you think of this idea? Would you be interesting in evolving your tool into that direction?

[matthiasbeyer]

That sounds like a perfect fit for cargo-changelog, yes!

Right now, cargo-changelog can record arbitrary (well, not that arbitrary, but still) data in the changelog entry header. A boolean is certainly supported already. Some querying mechanism for checking a range of changelog fragments for a certain values does not yet exist, IIRC.

I would love to see contribution for this, yes please!

[thomaseizinger]

Hmm, I was envisioning a more first-class support for this rather than querying and doing the processing outside the tool again.

I see the appeal in a very flexible tool but I am worried that it will be harder to adopt and understand if there are a lot of moving parts.

[matthiasbeyer]

Hmm, I was envisioning a more first-class support for this rather than querying and doing the processing outside the tool again.

Yes, me too! This is only the first step towards, I think! :wink:

[thomaseizinger]

FWIW, I prototyped something the other day: https://github.com/thomaseizinger/semverlog

I'll try it out in our workspace. Happy to converge the two tools if you want :)

[matthiasbeyer]

Hi! This looks neat! I would love to converge the tools, yes!