Consider not bumping versions in PRs

[thomaseizinger]

Currently, we follow the scheme of bumping versions in manifest files as the breaking change happens. Without automation (see #2902) this is tedious and may even result in repeated work across multiple PRs.

The main benefit of doing this right away is to make sure we don't forget about (breaking) changes but can instead trust in the correct versions being set as we do the final release.

With #2647, we will get notified about most breaking changes so at the latest, we need to get this CI check green in the release PR.

I would like to suggest that we only make changelog entries in PRs, perhaps using the output of the above CI check as a guidance to whether the change was breaking or not. Once we do the release, we only need to do the entire dance of bumping versions across the workspace once but can still have clarity that we don't forget anything.

However we solve it, I would like to get rid of the manual version bumping in each PR.

[mxinden]

Getting rid of the version bumps in pull requests would be wonderful. Only requirement from my end is that it doesn't happen at the expense of making releasing more difficult or error prone.

I would like to suggest that we only make changelog entries in PRs, perhaps using the output of the above CI check as a guidance to whether the change was breaking or not.

Say we have two pull requests 1 and 2. 1 does a breaking change, does not bump the version and is merged. The CI check on 2 will fail even if 2 does not do a breaking change. This would be confusing, right?

[thomaseizinger]

Getting rid of the version bumps in pull requests would be wonderful. Only requirement from my end is that it doesn't happen at the expense of making releasing more difficult or error prone.

What do you consider as "too difficult"? I totally agree with you that releasing should be easy and fast but that is not necessarily in opposition with doing more work as part of a release.

Consider this:

With the help of #2647, getting the next version number wrong is highly unlikely. Thus, each PR would only need to add a changelog entry without setting the new version. To actually perform a release, we can then use cargo semver-checks (with or without further automation / scripts) to set the correct version. Perhaps we can even chain together cargo semver-checks and cargo release somehow? Looking through cargo release's README, I see the following feature:

Updates dependent crates in workspace when changing version

It seems it would be possible to do more of this work at release time but automate it all so it is neither difficult nor error prone.

[mxinden]

Thus, each PR would only need to add a changelog entry without setting the new version.

Would one still update the version in the CHANGELOG.md or would one only add ones entry under a ## [Unreleased] section? In case we do the latter, how would one track breaking changes that are not breaking at the type level?

I suggest we:

• We get .github/workflows: Enforce semver compliance with cargo semver-checks #2647 merged.
• Update https://github.com/libp2p/rust-libp2p/blob/master/docs/release.md

Once that is done we can do the next release according to the new process.

[thomaseizinger]

Thus, each PR would only need to add a changelog entry without setting the new version.

Would one still update the version in the CHANGELOG.md or would one only add ones entry under a ## [Unreleased] section? In case we do the latter, how would one track breaking changes that are not breaking at the type level?

I would have thought that the version is still correctly recorded in the changelog, to make sure we don't need to do it a release time. This however is getting close to what co-vector seems to be doing so I'll go ahead an look into that.

[thomaseizinger]

I suggest we:

• We get .github/workflows: Enforce semver compliance with cargo semver-checks #2647 merged.
• Update master/docs/release.md

Once that is done we can do the next release according to the new process.

Yeah I don't think that needs to block the current release.