From 5018a64db89d3f8fb5231d0c56f90c59d53fe1af Mon Sep 17 00:00:00 2001 From: Rich Lander Date: Wed, 17 Jun 2020 10:42:52 -0700 Subject: [PATCH] Add proposal for breaking changes (#37779) * Add proposal for breaking changes Co-authored-by: Stephen Toub Co-authored-by: Jan Kotas Co-authored-by: Dan Moseley --- docs/coding-guidelines/breaking-changes.md | 2 +- docs/project/breaking-change-process.md | 50 ++++++++++++++++++++++++++++++ 2 files changed, 51 insertions(+), 1 deletion(-) create mode 100644 docs/project/breaking-change-process.md diff --git a/docs/coding-guidelines/breaking-changes.md b/docs/coding-guidelines/breaking-changes.md index 2d72223..5e4798c 100644 --- a/docs/coding-guidelines/breaking-changes.md +++ b/docs/coding-guidelines/breaking-changes.md @@ -1,6 +1,6 @@ # Breaking Changes -We take compatibility in .NET Framework and .NET Core extremely seriously. +We take compatibility in .NET Framework and .NET Core extremely seriously. We use the [breaking change process](../project/breaking-change-process.md) to manage and consider potential breaking changes. Although .NET Core can be deployed app local, we are engineering it such that portable libraries can target it and still run on .NET Framework as well. This diff --git a/docs/project/breaking-change-process.md b/docs/project/breaking-change-process.md new file mode 100644 index 0000000..cb8e83f --- /dev/null +++ b/docs/project/breaking-change-process.md @@ -0,0 +1,50 @@ +# Breaking change process + +Breaking changes make it difficult for people to adopt new versions of .NET. We strive to avoid making them. In the rare case when a breaking change is unavoidable or the best option when all factors are considered, you should follow the process outlined in this document. The intent of the process is to get feedback. This might result in previously unseen opportunities to achieve your goals without breaks, clever ways to limit breaks to more niche scenarios, and (most importantly) better understand the scope of impact to .NET users. + +This process does not result in approval or denial of a breaking change request. It results in feedback, which might be varied or uniform. In the best case, the feedback is a call to action to you, that provides a direction on how you should proceed. The people that are responsible for reviewing your PR are expected to use the information collected by this process as part of their determination of whether your change is appropriate to merge. + +You should start this process as soon as possible, preferably before any code is written, in the design phase. This isn't always possible, since the change in behavior might not be discovered until you're almost done building a feature. In the case of a significant breaking change, you should provide reviewers with a design document so that they can understand the broader scope, goals and constraints of your change. + +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 + +1. Create or link to an issue that describes the breaking change, including the following information: + * Mark with the [breaking-change](https://github.com/dotnet/runtime/labels/breaking-change) label + * Goals and motivation for the change + * Pre-change behavior + * Post-change behavior + * Versions of the product this change affects + * Errors or other behavior you can expect when running old code that breaks + * Workarounds and mitigations, including [AppContext switches](https://docs.microsoft.com/dotnet/api/system.appcontext) + * Link to the issue for the feature or bug fix that the breaking change is associated with. + * Reference this issue from associated PRs. +2. Share your issue with whomever you see as stakeholders + * Please @mention [dotnet/compat team](https://github.com/orgs/dotnet/teams/compat) team + * Engage with people commenting on the issue, with the goal of deriving the most feedback on your proposed breaking change + * This may involve significant explanation on your part. A well-written design doc can ease the burden here. +3. Mark associated PRs with the [breaking-change](https://github.com/dotnet/runtime/labels/breaking-change) label, and link to your breaking change issue. +4. Once the PR is merged, create a [docs issue](https://github.com/dotnet/docs/issues/new?template=dotnet-breaking-change.md). + * Clarify which .NET preview the break will be first released in. +5. Breaking change issues can be closed at any time after the PR is merged. Best practice is waiting until the change has been released in a public preview. + +Notes: + +* We add quirk switches to .NET Core re-actively, only once we get feedback that they are really needed for something important. We do not add them proactively like in .NET Framework just because they might be needed in theory. +* In terms of product versions that the change affects, consider both .NET Core and .NET Framework (see: [.NET Framework compatibility mode](https://docs.microsoft.com/dotnet/standard/net-standard#net-framework-compatibility-mode)). Consider source and binary compatibility. + +## Examples + +The following are good examples of breaking change issues + +* https://github.com/dotnet/runtime/issues/28788 +* https://github.com/dotnet/runtime/issues/37672 + +## Resources + +There are additional documents that you should consult about breaking changes: + +* [Breaking changes](https://github.com/dotnet/runtime/blob/master/docs/coding-guidelines/breaking-changes.md) +* [Breaking change definitions](https://github.com/dotnet/runtime/blob/master/docs/coding-guidelines/breaking-change-definitions.md) +* [Breaking change rules](https://github.com/dotnet/runtime/blob/master/docs/coding-guidelines/breaking-change-rules.md) -- 2.7.4