This repository has been archived by the owner. It is now read-only.

Déjà vu #2392

Merged
merged 2 commits into from Mar 14, 2018

Conversation

Projects
None yet
6 participants
@halter73
Member

halter73 commented Mar 14, 2018

Default to the managed socket transport

#2360

@halter73 halter73 requested review from davidfowl and natemcmaster Mar 14, 2018

@@ -17,9 +17,6 @@
<ItemGroup>
<ProjectReference Include="..\Kestrel.Core\Kestrel.Core.csproj" />
<ProjectReference Include="..\Kestrel.Https\Kestrel.Https.csproj" />
<!-- Even though the Libuv transport is no longer used by default, it remains for back-compat -->
<ProjectReference Include="..\Kestrel.Transport.Libuv\Kestrel.Transport.Libuv.csproj" />

This comment has been minimized.

@halter73

halter73 Mar 14, 2018

Member

@natemcmaster I left this comment the first time I switched the default transport to managed sockets. Doesn't removing this dependency break back-compat?

This comment has been minimized.

@davidfowl

davidfowl Mar 14, 2018

Member

This is the break only we're willing to take for 2.1.

This comment has been minimized.

@halter73

halter73 Mar 14, 2018

Member

To be specific, I think this change will break any existing app that references just the main Kestrel package and calls UseLibuv.

This comment has been minimized.

@natemcmaster

natemcmaster Mar 14, 2018

Member

Yes, this is an intentional breaking change that we decided is worth taking. It should only affect a small group of people since we are keeping Transport.Libuv in the .All metapackage. It only breaks for people who depend directly on the .Kestrel package, and they can fix this break by adding a package reference to K.T.Libuv when they upgrade to 2.1. IMO we should post this to aspnet/announcements as a heads up.

This comment has been minimized.

@davidfowl

davidfowl Mar 14, 2018

Member

Yep, that's known. This will be documented as a breaking change in 2.1.

/cc @DamianEdwards @Eilon

This comment has been minimized.

@Eilon

Eilon Mar 14, 2018

Member

Yup.

This comment has been minimized.

@halter73

This comment has been minimized.

@aateeque

aateeque Mar 17, 2018

Why are you breaking semantic versioning by introducing breaking change in a minor version increment?

This comment has been minimized.

@davidfowl

davidfowl Mar 17, 2018

Member

Because of the reasons listed here #2360. A few things are changing in 2.1 as well. We’re introducing a shared framework for ASP.NET Core and we’d prefer it if libuv wasn’t part of that. Also we feel like it will break few enough people that it shouldn’t matter that much. The workaround for people is also trivial and if you’re upgrading from ASP.NET Core 2.0 to 2.1 and you’re using the .All package everything still works.

Where things will break is if you were using .net Framework with libuv and were configuring the API explicitly (to say tweak the number of threads)

@davidfowl

This comment has been minimized.

Member

davidfowl commented Mar 14, 2018

@halter73 can you also stage various reaction PRs to other repositories using a feature branch (if there are any). I'll send a PR to benchmarks that explicitly adds the libuv package.

@halter73

This comment has been minimized.

Member

halter73 commented Mar 14, 2018

Absolutely! I'll get right to staging all the other reaction PRs 😉

@davidfowl

This comment has been minimized.

Member

davidfowl commented Mar 14, 2018

:trollface:

@halter73 halter73 merged commit 9901f0f into dev Mar 14, 2018

3 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
license/cla All CLA requirements met.
Details

@halter73 halter73 deleted the halter73/2360 branch Mar 14, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.