Consider running semver check only before release

[jbesraa]

Currently we run semver check for each PR and we also keep notes for any semver change in an issue. This feel like over-complicated.

I suggest to run semver only once before we start the release and catch all needed upgrades. I think we should do it in the last PR merged before the release start.

So the flow suggested here will look like this:

1. none of the PRs gets semver check in CI
2. once we decide the milestone is complete, we create a new PR with a "release" label
3. semver ci will be triggered on the "release" labeled PR
4. "release" labeled PR will be updated to fix semever ci
5. start actual release process

[plebhash]

I'm afraid this suggestion comes from the assumption that semver CI would conveniently remove the need to keep doing issues like #1345, but unfortunately that is not the case

semver CI will only point us to necessary MAJOR bumps (breaking changes), which means we still need to be disciplined on how we manage MINOR and PATCH bumps

if we only left management of MINOR and PATCH bumps to be done immediately before the release (by humans, CI is impossible), we would allow too much margin for human error, as we could miss things because there were too many PRs during the milestone

for MAJOR bumps, indeed we have two options:

• enforce before PRs are merged (current strategy)
• enforce before release

I'm not necessarily opinionated towards one or the other, but IMO the benefits of switching strategies are only marginal, and much smaller than what this suggestion seems to be aiming at

[jbesraa]

I'm afraid this suggestion comes from the assumption that semver CI would conveniently remove the need to keep doing issues like #1345, but unfortunately that is not the case

semver CI will only point us to necessary MAJOR bumps (breaking changes), which means we still need to be disciplined on how we manage MINOR and PATCH bumps

if we only left management of MINOR and PATCH bumps to be done immediately before the release (by humans, CI is impossible), we would allow too much margin for human error, as we could miss things because there were too many PRs during the milestone

for MAJOR bumps, indeed we have two options:

* enforce before PRs are merged (current strategy)

* enforce before release

I'm not necessarily opinionated towards one or the other, but IMO the benefits of switching strategies are only marginal, and much smaller than what this suggestion seems to be aiming at

So you have three options:
Patch: This should only be done if we are pushing a bug fix to a released version right? so this is currently always manual I think?
Major: This can be handled by semver ci check that runs only once on the final code before release
Minor: If it is not a patch or major, i.e., if we are not patching any bugs and semver is not complaining then we need to pump minor because you can't release the same package again with the same version.

[Fi3]

rust crates MUST follow semver so minor means that we are adding features (no removing or changing existing API, so no breaking change). So majior and miner both touch the API where majior introduce a breaking change minor does not. Patch do not touch the API.

[jbesraa]

Yea we agree on this. I think.
The goal here is to try to automate it better.

[GitGab19]

What would be the real benefit behind this?