Have we time to re-point HttpClientFactory at a new (signed) Polly v6.0.0 before RTM?

[reisenberger]

#105 reached the conclusion Polly should release only as a single, strong-named version to avoid sn / non-sn conflicts in the OSS ecosystem driven by the ASPNET Core2.1/Polly integration.

@DamianEdwards @glennc @rynowak /cc @joelhulen : Have we time before ASPNET Core 2.1 RTMs, to implement this and re-point HttpClientFactory (Microsoft.Extensions.Http.Polly) at the new Polly v6.0.0 ?

At the Polly end it is only a package/build change (no new code; delete some already-deprecated code), but we would need few days* to get it right and ripple across related Polly packages (six total?).

---

Most other scenarios sound painful ...

If Microsoft.Extensions.Http.Polly RTMs referencing Polly-Signed v5.9.0, and Polly shortly thereafter were to deprecate Polly-Signed and bump to Polly v6.0.0 as the single (signed) Polly package, we create more of exactly the pain we are trying to avoid. Microsoft.Extensions.Http.Polly would hold users to including Polly-Signed, whereas other projects (or the desire to adopt new features) would drive users to the new Polly >=v6.0.0 package. But the two would clash at compilation time as prev highlighted.

In fact if Microsoft.Extensions.Http.Polly had to RTM referencing Polly-Signed v5.9.0, we may likely be better waiting on packaging changes to Polly until Microsoft.Extensions.Http.Polly could be re-released referencing Polly >=v6.0.0. If there were several months to that [EDIT: if needing to wait for eg Core 2.2], some Polly users/projects would hit the pain of both packages having a strong presence in the market in that period.

Also: Would changing Microsoft.Extensions.Http.Polly from referencing Polly-Signed v5.9.0 to Polly v6.0.0 after release, be considered (from semver perspective) a breaking change to Microsoft.Extensions.Http.Polly that affects release numbering, or not?

... all seems to point to ideally doing this before RTM?

EDIT: if sensitive to discuss the ASPNET Core 2.1 RTM date via this forum , @rynowak and @glennc do have direct email for myself and @joelhulen

[rynowak]

I agree this would cause a lot of pain given the plans. Let me talk to folks on our side.

[rynowak]

@reisenberger @joelhulen - it's very likely that we'll get approval to do this.

[joelhulen]

@rynowak Great! Thank you :) We're working on this now. Please stay tuned...

[reisenberger]

@rynowak @glennc A new Polly 6.0.0-v6alpha package is up on nuget, based on this PR, adopting the new single-signed-package philosophy.

We will go through the same procedure now for Polly.Extensions.Http, the other you need as a direct dependency for Microsoft.Extensions.Http.Polly.

[iancooper]

@reisenberger Should we depend on this, or wait for a non-alpha package i.e. what version are you likely to go with for 2.1 RTM?

[reisenberger]

@iancooper Polly v6.0.1 (rtm, non-pre-release) should publish to nuget in the next 24 hours. Functionally, the content is identical to the 6.0.0-v6alpha package we trialled couple days ago.

@rynowak @glennc And Polly.Extensions.Http v2.0.1 in the same timeframe, as agreed.

@rynowak @glennc Thanks to you and the wider ASPNET Core team for the teamwork to get this best versioning/strong-name strategy in the market.

[joelhulen]

@iancooper @rynowak @glennc Polly v6.0.1 and Polly.Extensions.Http v2.0.1 (both RTM) have now been published to nuget.org. Thanks to each of you for raising the issue, and helping work to the best path forward. Thanks to @reisenberger for pushing hard the last few days to get these changes in place!

[rynowak]

6194618 in release/2.1

[iancooper]

Thanks all. We'll get to work.