Thomas Eizinger

We discussed this in our open maintainers call and @rkuhn suggested that instead of failing CI on detected breaking changes via `cargo semver-checks`, we could just flag the PR with...

Perhaps a good combination of automation would be to: 1. Use `release-please` to open the release PRs and have it generate the changelog. 2. Run `cargo semver-checks` as we currently...

> Heads-up that development has started on a v2 of the cargo-semver-checks GitHub Action ([obi1kenobi/cargo-semver-checks-action#21](https://github.com/obi1kenobi/cargo-semver-checks-action/pull/21)). A new feature we're considering for v2 is the ability to apply labels to PRs...

## The perfect process In a perfect world, I think this would be a good process: - Use `cargo semver-checks` at release time to pick the appropriate version bump for...

Had a chat with @mxinden today about this. We definitely want to keep the PR squash-merging strategy. Unfortunately this means that pretty much every tool / strategy that extracts changelog...

In a 2nd step, I'd like to move away from bumping versions as part of the pull request and instead only capture what bump is necessary given the changes since...

The story of https://github.com/libp2p/rust-libp2p/pull/3312#issuecomment-1444604719 is another data point towards not bumping versions in PRs. It hides from us, which changes would be breaking in lieu of what is already merged.

> If you decide to go the metadata route, you can use the value of the `next-bump-level` field to populate the `--release-type` flag when invoking `cargo-semver-checks`. This would avoid having...

This makes me think we might want to go back to the idea of structured changelogs: - Collect changelog entries as individual files with a structured format, something like: ```toml...

> ```toml > semver-bump = "minor" > ``` Actually, what we should be tracking is `breaking: true/false` and infer the next bump from the current version + that.