Deprecated packages

[RomanDvorsky]

When do I run the dotnet list package --deprecated --include-transitive --source nuget.org command over my solution I do find out these deprecated packages:

System.IO.Pipelines                              5.0.1      Other,Legacy
System.Threading.Channels                        5.0.0      Other,Legacy
Microsoft.Bcl.AsyncInterfaces                    5.0.0      Other,Legacy

Both are transitive packages referenced by StackExchange.Redis Version="2.6.122"

Any plan to upgrade these packages in your solution?

[NickCraver]

No plans to change those, but you are welcome to reference newer versions directly if you want to upgrade. We maintain the widest compatibility possible, which means the lowest reference we can reasonably take.

[RomanDvorsky]

well I agree to keep lowest reference, however you want to support deprecated packages?

I did upgrade the package in my solution however this is what scares me a bit:

[NickCraver]

Yes, we want to support them. We can't make millions of users upgrade every time any dependency drops support. Those who have an issue can upgrade, those who don't are okay to upgrade or not. Complex solution and dependency trees create immense maintenance and testing pain for teams, we do not want to churn them unless we have to.

[RomanDvorsky]

well if you support deprecated package it gives me 2 options now:

• I will use deprecated package - which I do not want
• I will upgrade given packages directly and risk that your solution get broken maybe in runtime (there are major changes in those packages)

Am' I right or I do miss something?

[NickCraver]

That's correct, though we know of no issues upgrading those even to latest.

To put this in perspective: if we did upgrade those, we'd be making that decision to break all other libraries that depend on the same transitive library, and taking it out of your control.

[RomanDvorsky]

well honestly I do not know any company who want to have deprecated packages in their solution however I do know a lot of companies who has problem to take a risk of breaking their solution.

If I would be a package owner I would not depend on any deprecated or vulnerable package but of course the decision is yours.

Actually I do not see any problem if you deliver new version to keep decision on the owners whether they want to stay on old version or want to upgrade. From my perspective you are taking option of delivering reliable software to pushing us either risk or keep deprecated package.

Currently I do not see any other option than recommend product owner to use other solution than your package because this approach seems risky in the long term perspective.

[NickCraver]

If I would be a package owner I would not depend on any deprecated or vulnerable package but of course the decision is yours.

You would be constantly updating then, and forcing your users to do so.

Actually I do not see any problem if you deliver new version to keep decision on the owners whether they want to stay on old version or want to upgrade. From my perspective you are taking option of delivering reliable software to pushing us either risk or keep deprecated package.

This means perfectly working users couldn't get upgrades, without also taking the package upgrades, so yes: there is a problem.

Currently I do not see any other option than recommend product owner to use other solution than your package because this approach seems risky in the long term perspective.

That's your perspective, and it's valid. But constant upgrades in large systems are more risky to most people.

As someone who maintains (and helps a great many others) maintain large and complex systems, I cannot overstate how much you're drastically dismissing and underestimating the cost of upgrades here. We're talking about multiple versions and cascading downstream dependency shifts across versions to say nothing of feature branches, cherry-picks, etc. in maintaining live systems deploying often to many millions of machines. Moving transitive dependencies and binding redirects is super painful for many teams, so we opt to minimize that pain.

[RomanDvorsky]

Well, this is something we are not going to agree on. I think that if you need to upgrade your package you can afford to maintain whole solution. I do not see a point of upgrading one package and do not get rid of all vulnerable packages. I do not want to upgrade to latest version I would like to see least not deprecated package - just to be up to date.

But feel free to close this - we are not going to get anywhere - I think you are wrong, you have your reasons to not agree, that's life :)

[NickCraver]

Fair enough - I think most people don't really grok the magnitude here, it's perspective that's accumulated when supporting millions of users.

[RomanDvorsky]

I do not agree - why Microsoft release new versions, why they deprecate packages? You just have to move on and the trade - support for risk seems wrong to me - but what can I do? :)