How do NuGet package authors avoid version Hell?

Question

Assume I want to publish a NuGet package at nuget.org.

It depends on, for example, Newtonsoft.Json. So I set this dependency in the .nuspec and include a N..Json version number of 1 (for args sake).

If N..Json moves on to 2, and people using my package also move to 2, then are they now in a pickle because my package wants 1 and they're using 2?

Presumably, to add my package in the first place, they'd have to have either not already have N..Json installed or if they did, be on the exact version my package uses.

I guess stipulating an exact version is bad. So I omit the version, but now my package may break in the future if N..Json has breaking changes.

Instead, I add a range in my .nuspec and now I'm part way there.

But haven't I just imposed a ceiling on all my customers on what max version of N..Json they can use?

Do I now need to keep an constant eye on the versions of the packages that my package uses and ensure I'm testing for the rest of my life?

Is there some system over at NuGet.org that can alert me that my package has fallen behind or might be impacted by breakers in other people's work?

What will happen if customers try and globally update N..Json to the latest, will it be obvious that my package is a blocker?

What's the established best practice?

Answer 1

I do not believe nuget.org offers any help with version management. You should follow semver.org guidance for versioning your packages and your package dependencies. This may cause an issue for people who already have a higher version of your dependent package installed. However, nothing prevents you from having multiple versions installed side by side.