Skip to content

Conversation

@natemcmaster
Copy link
Contributor

Resolves https://github.com/aspnet/AspNetCore-Internal/issues/1940

This adds support for listing a reference removal as an allowable breaking change.

<Reference Include="System.Runtime.CompilerServices.Unsafe" />
</ItemGroup>

<ItemGroup Condition="'$(AspNetCoreMajorMinorVersion)' == '3.0'">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is technically a new package in 3.0.

We replaced the old Microsoft.AspNetCore.SignalR.Protocols.Json package with the Microsoft.AspNetCore.SignalR.Protocols.NewtonsoftJson package and then removed the old one.

So this is now a new package and probably shouldn't have a baseline associated with it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even so, it's the same package ID and the build system (and users) see this as a breaking change. It's okay since this was planned. This documents that intention in the code.

@@ -0,0 +1,17 @@
Build Errors
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👏 👏 👏 👏 👏 👏

</ItemGroup>

<ItemGroup Condition="'$(AspNetCoreMajorMinorVersion)' == '3.0'">
<!-- This dependency was replaced by Protocols.NewtonsoftJson between 3.0 and 2.2. This suppression can be removed after 3.0 is complete. -->
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we file an issue to do this after branching for 3.0? I guess it's not a big deal if we don't remove it right away.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, such an issue is likely to get lost between now and RTM if it has to wait in the backlog. But, if you create a 4.0 milestone for it, that'll work.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't need to file an issue, this will go away when we make System.Text.Json the default.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't hurt if it stays around, but feel free to file an issue to clean up later. I'm writing these suppressions with the condition that checks version to makes sure the code doesn't become a problem later when we branch for 3.1 and beyond.


> error BUILD002: Package references changed since the last release...
Similar to BUILD001, but this error not suppressable. This error only appears in servicing builds which should not change references between assemblies or packages.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor but this will slow readers: "error is not…"


## Example: make a breaking change to references

If Microsoft.AspNetCore.Banana in 2.1 had a reference to `Microsoft.AspNetCore.Orange`, but in 3.0 this reference is changing to `Microsoft.AspNetCore.BetterThanOrange`, you would need to make these changes to the .csproj file
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🍌 is already better than orange (🔶) ❕

</ItemGroup>

<ItemGroup Condition="'$(AspNetCoreMajorMinorVersion)' == '3.0'">
<!-- This dependency was replaced by Protocols.NewtonsoftJson between 3.0 and 2.2. This suppression can be removed after 3.0 is complete. -->
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, such an issue is likely to get lost between now and RTM if it has to wait in the backlog. But, if you create a 4.0 milestone for it, that'll work.

@dougbu
Copy link
Contributor

dougbu commented Apr 16, 2019

Hard to tell but the build failures in attempt 1 are likely flakiness. I started attempt 2.

@aspnet-hello
Copy link

This comment was made automatically. If there is a problem contact ryanbrandenburg.

I've triaged the above build. I've created/commented on the following issue(s)
https://github.com/aspnet/AspNetCore-Internal/issues/2267

@Eilon Eilon added the area-signalr Includes: SignalR clients and servers label Apr 16, 2019
@natemcmaster natemcmaster merged commit 607cbc3 into dotnet:master Apr 16, 2019
@natemcmaster natemcmaster deleted the warnings-about-changes branch April 16, 2019 16:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area-signalr Includes: SignalR clients and servers

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants