#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
#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