-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add proposal for breaking changes #37779
Conversation
Add link to this doc from https://github.com/dotnet/runtime/blob/master/docs/coding-guidelines/breaking-changes.md ? |
@jkotas -- it appears there is a link to that doc in the PR. Yes? https://github.com/dotnet/runtime/pull/37779/files#diff-3e4368228ffed87f000e514b5d3fe593R42 |
I meant link in the opposite direction to make this new doc easier to discover. |
|
||
There are people on the team that can help you work through a breaking change, if you want to engage with them before starting this more formal process. They are part of the [dotnet/compat team](https://github.com/orgs/dotnet/teams/compat) . Feel free to @mention them on issues to start a dialogue. | ||
|
||
## Process |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we supposed to create new issues for issues that track design work in case this design has been identified as potentially being breaking or is it OK if we apply this label to such issues?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That one is easy. You should create an issue when you start wanting feedback (not solely on compatibility).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left some questions, but I love this direction
Co-authored-by: Stephen Toub <stoub@microsoft.com>
I think I covered the feedback, now. Thanks! I added an explicit rule on when an issue should be closed. Seemed like a case to cover. Good? |
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
@PriyaPurkayastha should sign off. |
Co-authored-by: Dan Moseley <danmose@microsoft.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. Thanks.
Thank you! |
A few of us have been thinking about how to better handle breaking changes in this repo. I've taken those ideas and written them in the doc. Please share your feedback.
If this new model is successful, we'll apply it to other repos.
Conversation started here: #37689
Several other people helped on this proposal: @AaronRobinsonMSFT, @jkotas, @marklio, @PriyaPurkayastha, @jamshedd, @stephentoub, @danmosemsft