What this PR does
Contributing guide and PR template say how to mark a breaking change, ! after type/scope or a BREAKING CHANGE: footer, but nothing says what makes a change breaking. This PR adds that to docs/agents/contributing.md: after the upgrade an existing install, client or consumer is refused, loses something it used, or has to be edited to keep working.
The case that showed the gap is #4973. It was a fix that made a values shape the previous version ran fail at render time. It merged with a release note about it and without !, and no written rule decided it either way.
The definition follows what maintainers already mark with ! on merged fixes, it is not a new policy: #4847 (runtime refusal), #4639 and #4796 (refusal only for new or changed objects, existing ones keep working). Not breaking: a change that only accepts more, makes something broken work, refuses only what never worked even if it rendered or deployed, or changes how a working install runs while it keeps working. Refusing what never worked is how #4973 treats its own no-sizing pool, and it is why #4567 was a plain fix.
I walked the text against #4973 and #5083 (breaking, both merged without !) and against #4220, #4974, #3935 (not breaking). One place it differs from a marker: #4569 has !, but its value rendered and KubeVirt never admitted it, so by this text it is not breaking.
The text also says the fix type does not exempt a change, and an Action required line in the release note does not replace the marker. PR template tip line links to the new section (link works after merge, same as the backports one next to it).
A default change that degrades a working install without failing it is not covered. If it should be, please say so here.
contributors/README.md in cozystack/community repeats the marker syntax and has no definition either. No follow-up there yet, so the downstream boxes stay empty.
Not in this PR: labels.yml, pr-labeler.yaml, the release docs, and a check for Action required without the marker.
Screenshots
Downstream repositories
Release note
docs(contributing): the contributing guide now defines a breaking change (after the upgrade an existing install, client or consumer is refused, loses something it used, or has to be edited to keep working), says the `fix` type does not exempt a change and an `Action required` line in the release note does not replace the `!` marker. The PR template links to it.
Summary by CodeRabbit
- Documentation
- Added clearer guidance on what qualifies as a breaking change, including examples of changes that are not breaking.
- Linked the pull request template’s breaking-change guidance to the contributing documentation.
- Clarified that commit markers and release notes are separate requirements.