Update breaking-change-guidelines.md #47797
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ghost
added
Contributor
There was a problem hiding this comment.
Pull Request Overview
This PR updates the .NET SDK breaking change guidelines to include considerations for IDEs and code editors as well as clarifying the correct usage of the breaking-change label.
- Expanded guidance to address discrepancies in update cadences for IDEs and other tooling
- Revised instructions to add the breaking-change label on pull requests when submitted for an issue
Comments suppressed due to low confidence (1)
documentation/project-docs/breaking-change-guidelines.md:7
- Consider rephrasing 'Same applies to other IDEs and code editors from the wider .NET community.' to 'The same applies to other IDEs and code editors from the wider .NET community.' for improved clarity.
In general, we want to make updating the .NET SDK as smooth as possible for developers. This extends to .NET tooling such as IDEs and code editors which may have a different release schedule and cadence. For example, the .NET 9 SDK (which was a new major version) was released with Visual Studio 17.12 (which was a new minor version). In this example, breaking changes in the .NET 9 SDK could disproportionally impact Visual Studio users who are expecting incremental, non-breaking, changes in the new minor version. Same applies to other IDEs and code editors from the wider .NET community.
marcpopMSFT
reviewed
Mar 21, 2025
| * Add the breaking-change label to the issue. This label should be available in all .NET repositories that ship as part of the .NET SDK. If the label is not available, please file an issue in [dotnet/sdk](https://github.com/dotnet/sdk). | ||
| * The issue will trigger a message with instructions to add documentation. In addition, you are invited to work with the SDK team to publish a blog post for the change. | ||
| * Consider creating and pinning an issue in the appropriate GitHub repository where the community can provide feedback. | ||
| * Once a Pull Request is submitted for the issue, add the breaking-change label to the Pull Request as well. This will trigger a message with instructions. In addition, you are invited to work with the SDK team to publish a blog post for the change. |
Member
There was a problem hiding this comment.
Should there be a link to the docs repo where the breaking change would be filed or leave that to the instructions?
marcpopMSFT
approved these changes
Mar 21, 2025
aortiz-msft
deleted the
aortiz-msft-sdk-breaking-change-guidelines-updates
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Update .NET SDK breaking change guidelines with a note about IDEs and code editors; clarify the use of the breaking-change label.