search

NuGet / Home

Repo for NuGet Client issues
Other
1.5k stars 252 forks source link

Best practices on handling package evolution #2863

Closed etiago closed 8 years ago

etiago commented 8 years ago

Hi everyone,

Are there best practices from the NuGet team on how to handle the evolution of dependencies? Namely, how frequently do you recommend checking for new versions and do you have/use tooling to proactively bring the developers' attention to when there are, e.g., security vulnerabilities in a certain version of a package which should be migrated to a newer version?

For NPM packages I found such a tool (David) which allows to programatically check whether there are new versions and whether there are security vulnerabilities in certain versions of packages.

I'm also interested in license compliance. In particular compliance of dependencies of dependencies. Imagining that I depend on package A, which in turn depends on package B, if eventually package B moves to a different licensing model (e.g., MIT to GNU GPL), is there tooling or a procedure already in place that allows us to detect this?

Many thanks in advance for any input!

Regards, Tiago

harikmenon commented 8 years ago

Going forward, we recommend that you ask questions on StackOverflow, we have started to actively answer questions there. We want to keep GitHub issues primarily for feature requests/bugs at this time.

To your first question, there is no tooling at this time that actively lets you know that a new version is available other than the badge count in the Updates tab in the Packet Manager UI in Visual Studio. You can look into using some community tools like http://nugetfeed.org/ that enables you to track updates (I believe they don't do pre-release versions, but I could be wrong).

On the issue around licensing. There are no tooling (that I'm aware of) at this time that enables you to determine programmatically or otherwise if there is a license change. Manual audit seems to be the best case option at this time. A lot of enterprises, to manage licenses, prohibit install of packages from NuGet.org and instead host a mirror version of the required packages and their dependencies on services like VSTS/TFS and myGet. These are the blessed set of packages and their dependencies that they will allow the developers in the org to install. The packages are archived to these feeds after due diligence on their part.

Saying that, I believe there is a lot of merit in both of these questions/ideas and we will consider adding them to our future backlog. Closing the issue as a question for now, will monitor for responses though :)

etiago commented 8 years ago

@harikm86 many thanks for the answer, and my apologies, I didn't know questions should go to SO :smile: