Add SYSLIB0013 into obsoletion list

[aik-jahoda]

Add obsoletion of Uri.EscapeUriString to the list.

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[jeffhandley]

Thanks for taking care of this, @aik-jahoda. We will also need to get a document created for this along with the corresponding aka.ms link too so that it shows up here and has its own page/deep link.

/cc @GrabYourPitchforks and @gewarren

[karelz]

SYSLIB0013 documentation: https://docs.microsoft.com/en-us/dotnet/fundamentals/syslib-diagnostics/syslib0013
Obsoleting discussion in #31387

[aik-jahoda]

@ericstj - this PR is already closed. Should I add the aka.ms link, or is something else required?

[aik-jahoda]

Here is detail about what was done: #31387 (comment) I believe we can remove needs-breaking-change-doc-created from this PR

[ericstj]

@aik-jahoda in the future feel free to remove that label once the doc is created.

[karelz]

The key question here was: Do we have a master doc which lists all obsoletions as one breaking change?
And is that enough for obsoletions?

@ericstj @jeffhandley would you know?

[aik-jahoda]

@karelz are you referring to this change? https://github.com/dotnet/runtime/pull/44203/files

[ericstj]

I see. I don't believe we have a master doc for obsoletions. Each obsoletion will have a different reasoning and call to action, just like any other breaking change. Can you please fill out the template here: https://github.com/dotnet/docs/issues/new?assignees=gewarren&labels=breaking-change%2CPri1%2Cdoc-idea&template=breaking-change.yml&title=%5BBreaking+change%5D%3A+

[gewarren]

We do keep have a breaking change article for each release for obsoletions with custom IDs. For .NET 6, it's https://docs.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/6.0/obsolete-apis-with-custom-diagnostics.

[ericstj]

@gewarren does that mean you don't feel that these need a separate breaking-change issue filed? If so we can update our process.

[gewarren]

@ericstj When you say "these", do you mean SYSLIB0013? If so, that one's already in the list. But if you're talking about others going forward, yes, please do file a new breaking change issue for them.

[ericstj]

I see, so this one only doesn't need a breaking change issue because it happened to be covered in this change: dotnet/docs#25988

I guess the rule here is "if someone has manually added the breaking change to documentation in under https://github.com/dotnet/docs/tree/main/docs/core/compatibility then you don't need to file a breaking change issue" Would that summarize it? I just want to make sure we aren't missing something in the process that would lose out on making a connection to our breaking change documentation. In the past we've always filed issues for every breaking change cc @PriyaPurkayastha

[gewarren]

We had been lumping the SYSLIB obsoletions into a single issue that I actually created, but that didn't work so well for a couple of reasons, so going forward we want each obsoletion to have its own issue. Just like any other breaking change. Sorry for the confusion.

[ericstj]

Makes sense, thanks @gewarren! You helped clear things up.

[karelz]

Thanks @gewarren for clarification. Looks like we have the SYSLIB0013 obsoletion already in the list of .NET 6 breaking changes. We are covered and no more work is needed. Thanks!