[DONE; update documentation] publish Polly v6.0.0 as strong-named only

[reisenberger]

CONSIDER publishing Polly v6.0.0 as strong-named only

Background

ASP.NET Core 2.1 is moving to consume Polly for HttpClient instances created through HttpClientFactory. This will allow the easy application of Polly resilience strategies to outbound calls through HttpClient.

This will significantly increase consumption of Polly's strong-named package (currently labelled Polly-Signed). That however will create conflicts for packages or projects that currently consume non-strong-named Polly: example; longer discussion.

There is no easy answer to this problem, as attested by discussion on numerous projects: octokit and the many projects that reference that issue.

Options:

• Be purely non-strong-named: project cannot then be consumed in environments or by upstream packages mandating strong-naming; not an option for Polly due to ASP.NET Core.
• Offer both strong-named and not (as Polly currently): but creates conflicts where a project ends up transiently referencing both.

Or:

Publish only strong-named

Some consensus among high-consumption projects now is around this, the NewtonSoft.Json strategy, as the least of all evils. @JeremySkinner of FluentValidation sums it up well here as does @sharwell elsewhere. I summarise also here.

TL;DR Switching to release Polly as strong-named only would be a one-time hit breaking change for consumers of Polly. But thereafter, having only the strong-named version of Polly in the market would prevent/reduce those conflicts (strong-named versus not) going forward.

(edited: for typos)

---

This is a proposal on which we would appreciate evidence-driven feedback. Particularly any consumption scenarios we may not be aware of. The proposed change is driven by the HttpClientFactory ASP.NET Core integration, which will drive many more Polly users to the strong-named version. ASP.NET Core has prior decision to be strong-named and thus consume strong-named assemblies.

[joelhulen]

I am leaning toward publishing only strong-named, starting with version 6.0. This would result in us ceasing the Polly-Signed lineage, and we'd need to make it very clear in several places that the assembly in the Polly package is strong-named.

I had initially thought of having a new namespace called something like PollyCore that is strongly signed, and maintain that separately like we do with Polly and Polly-Signed, in order to reduce conflicts. Then thought better of it as adding more confusion and then dealing with ambiguous method names, etc. when you bring in HttpClientFactory to an existing project that uses Polly already. The other downside is that you'd have two identical DLLs, but with different names. This is not ideal for various reasons.

[JamesNK]

I am leaning toward publishing only strong-named, starting with version 6.0. This would result in us ceasing the Polly-Signed lineage, and we'd need to make it very clear in several places that the assembly in the Polly package is strong-named.

.NET Framework treats changing the signing key on the assembly, including adding and removing one, as a different assembly. That means all libraries that depends on the package will break when someone upgrades to your new package until the library is recompiled.

That is fine for apps - people will recompile after upgrading packages - but other NuGet packages they use that depend your package will break until they are upgraded.

Read up on what happened when log4net changed its key.

This situation might have improved on .NET Core.

[iancooper]

I commented over here that consistency in the ecosystem is probably the best outcome we can hope for. The push to signed policy created by asp.net HttpClientFactory is essentially a fait accompli here, we are all going to have to take the signed version. So it would be easier to create a pit of success.

Strong naming is problematic, but I won't solve that problem...

[reisenberger]

Briefly to add some stats around the dependent packages issue highlighted ^^ by @JamesNK (thanks!), I don't know if the following stats are accurate/complete, but libraries.io helpfully gives us some idea of the packages currently dependent on Polly unsigned:

• dependent packages - 163
• repos - 267

EDIT: To estimate the ripple out effect more: The number of dependent packages is as above, but the number of dependent packages that in turn have widespread consumption is small (ie projects with more than a handful of stars per libraries.io; some ad-hoc checks suggest this has correlation with high downloads).

[holytshirt]

Brighter project will depend on this change
BrighterCommand/Brighter#287

[sharwell]

💭 Is adding a strong name a binary breaking change for applications that are not strong-named? It's been so long since I did anything with an assembly that wasn't strong named that I'm not sure the answer.

[reisenberger]

x-ref input from the Dot Net team

[iancooper]

@sharwell Yes, see this Brighter issue where we are tracking: BrighterCommand/Brighter#286

[iancooper]

But, we are happy to go this route. It seems to be the best path forward. We'll have to release as a 'breaking change' but we can live with that issue.