Discussion: add "semver:n/a" label

[robdimsdale]

We have automation that picks up the existence of semver labels on PRs (e.g. semver:patch) and uses that to determine the version of the next release. We require all PRs to have a semver label.

But often we have commits that don't impact the product at all. Examples include bumping test libraries (and test timeouts), and modifying CI/tooling. Currently we label these as semver:patch but that means we can't differentiate those changes from meaningful patch releases (like actual bugfixes). This makes it harder to determine whether to publish a release if it is a patch release, as we have to look at each commit to determine if it is a meaningful change that impacts consumers, or a commit with no user-impact.

If we agree that these non-impactful changes should not need semver labels, then I propose giving them a new label: semver:n/a. This allows us to continue to requiring that all PRs have a semver:XYZ label, which in turn allows us to continue determining the versions easily and automatically based on semver labels.

There would be changes required to the automation to handle this new label (e.g. don't create a draft release if there are only semver:n/a labels) - I am not proposing we solve that problem at this time.

[ryanmoran]

There would be changes required to the automation to handle this new label (e.g. don't create a draft release if there are only semver:n/a labels) - I am not proposing we solve that problem at this time.

My only concern would be that if we don't have some sort of gate, then we may risk accidentally releasing 2 copies of the same version.

[robdimsdale]

My only concern would be that if we don't have some sort of gate, then we may risk accidentally releasing 2 copies of the same version.

Yeah, I agree that we should prevent accidents like that. I tried to create two releases with the same version on a sandbox repo, and I wasn't able to do this - GitHub gave me an error. I haven't fully explored what the ramifications for our automation would be, but I suspect we might have to modify the jobs that create a release to avoid creating a release at all if the version matches the last published version.