New strategy on merging PRs and doing minor releases

[thomaseizinger]

I'd like to propose a new strategy for when to merge pull requests.

Previously, we just merged a PR when it was ready and if it needed a breaking change, we just bumped the versions. Not only does this attract more breaking changes because "the damage has already been done". It also means cargo semver-checks will (in the configuration we are using it in) not actually run any checks because with a minor bump in place, anything goes.

I've started with a milestone that marks the next breaking release (v0.52). What I'd like us to do is include issues and PRs in there that need a breaking change.

The main benefit I am expecting from this is that we will build up a feature-set in master that can be released as patch versions. Once we decide to make a breaking change, we can do a series of patch releases just before that and ship features to our users without the pain of cascading version bumps.

Additionally, because we will hold off on merging PRs that are breaking, I hope that this creates an incentive to ship features as non-breaking changes.

Let me know what you think of this @libp2p/rust-libp2p-maintainers.

[thomaseizinger]

Cross-referencing a discussion started somewhere else about this: #3522 (comment)

[mxinden]

To add an alternative, we could as well merge non-breaking changes to the release branches (e.g. v0.51) first, and then forward-port them to master.

That way we can release non-breaking changes regularly (or even for each feature) from the release branches and breaking changes from master every month.

[thomaseizinger]

Yes although that is a bit awkward, isn't it? I think the more standard workflow here would be to backport the non-breaking change to one or more older versions and keep making point releases but have master already be tracking the next breaking change.

On the whole, I'd rather not adopt such a workflow. I think it adds too much overhead and my hope would be that by not merging these breaking changes, we end up making fewer.

All I am proposing is a light-weight way of managing breaking changes rather than just making them at some point.

[thomaseizinger]

Closing this as we are now following this strategy.