same comment: microsoftgraph/msgraph-sdk-dotnet#812 (review)

@baywet we were talking about the nature of these "breaking changes" with @MIchaelMainer and we think that we need to define the process for these. Some common situations and what we are doing as far as I observed:

1. If a PR includes a breaking change for functionality that is working.
   We block the PR and trigger rollback on either metadata or new code in generator.
2. If a PR is introducing new functionality with a contract breaking change.
   We require a major version bump
3. If a PR includes a breaking change in technical terms, i.e. breaking the signatures in the SDK, but it is fixing a broken functionality and the assumptions is that nobody could have taken a dependency on it.
   Current process allows these types of changes without a major version bump. But we should discuss if there is any subset which should be excluded from this practice.

In addition to these PR/code review stage decisions, we need a definition of what needs to happen if a breaking change goes out accidentally. And this will most likely be language-specific depending on the constraints of package management systems.

• Do we roll back the latest release?
• Do we override the latest release?
• Do we add a new release and mark the problematic release somehow?
• Do we need a blog post or other communication mechanisms to let the users know?

I will share this in the Teams channel for discussion.

same comment: microsoftgraph/msgraph-sdk-dotnet#812 (review)

This confusion is resolved.