Skip to content
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

Merged
merged 10 commits into from
Jun 17, 2020
Merged

Add proposal for breaking changes #37779

merged 10 commits into from
Jun 17, 2020

Conversation

richlander
Copy link
Member

@richlander richlander commented Jun 11, 2020

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

@richlander richlander added the breaking-change Issue or PR that represents a breaking API or functional change over a prerelease. label Jun 11, 2020
@jkotas
Copy link
Member

jkotas commented Jun 12, 2020

@richlander
Copy link
Member Author

@jkotas -- it appears there is a link to that doc in the PR. Yes?

https://github.com/dotnet/runtime/pull/37779/files#diff-3e4368228ffed87f000e514b5d3fe593R42

@jkotas
Copy link
Member

jkotas commented Jun 12, 2020

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
Copy link
Member

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?

Copy link
Member Author

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).

Copy link
Member

@terrajobst terrajobst left a 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

@richlander
Copy link
Member Author

richlander commented Jun 17, 2020

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>
@danmoseley
Copy link
Member

@PriyaPurkayastha should sign off.

richlander and others added 2 commits June 17, 2020 08:37
Copy link

@PriyaPurkayastha PriyaPurkayastha left a 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.

@jkotas jkotas merged commit 5018a64 into dotnet:master Jun 17, 2020
@jkotas
Copy link
Member

jkotas commented Jun 17, 2020

Thank you!

@richlander richlander deleted the breaks branch June 17, 2020 18:05
@ghost ghost locked as resolved and limited conversation to collaborators Dec 8, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-Meta breaking-change Issue or PR that represents a breaking API or functional change over a prerelease.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants