search

matthiasbeyer / cargo-changelog

Changelog management tool for the CLI
Other
23 stars 1 forks source link

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

Open thomaseizinger opened 1 year ago

thomaseizinger commented 1 year ago

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:

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

matthiasbeyer commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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