16

I understand that NuGet packages update process is not automatic for a good reason (a new version could break your code or cause unforeseen problems), but then it transfers the responsibility of updating all packages to the developers themselves. When exactly should we be updating NuGet packages for a given project? Are there some guidelines regarding this process?

In our current project, this is more or less arbitrary: I update packages whenever I remember to check for updates, and preferably at the start of a sprint so that, if there are problems with the newer versions, we are able to fix them or rollback to the previous versions of the offending package. Most of the time, I'm the only developer that worries about this stuff, but I feel it is valuable to always be as up to date as possible because of performance reasons and new features that can make our work easier.

julealgon
  • 7,072
  • 3
  • 32
  • 77
  • 1
    Good question. I seem to recall a plugin developer state that you should only update when needing to, such as for a bug fix or new feature. But that doesn't really seem to be a comprehensive strategy. – James John McGuire 'Jahmic' Nov 08 '18 at 09:56
  • @Jahmic: Agree. That developer might take the "if it ain't broken don't fix it" kind of strategy, but then he must be prepared to end up in technical dept. He could be several majors behind on an important security update, hence complication implementation of this update and having to deal with a potentially huge QA/test effort. At least before a given version of a nuget is no longer maintained, the update to a maintained version should have taken place. – Vering Nov 13 '20 at 10:42

2 Answers2

15

Well, you should update whenever you are able to cope with it.

So you need to think carefully about the regression updating the packages could cause to your application if already in production, or the extra tests you are going to need to carry on in order to verify everything seems to be working as expected.

Normally updating to newer minor versions shouldn't cause much problems, but you always have the risk of it. Looking at the newer version release notes could prepare you to what to expect of the update.

In summary, update when you can cope with it, and you are ok with any shouting from your testers if suddenly the system regress without them even knowing it was coming :)

Juan
  • 3,675
  • 20
  • 34
  • 10
    Great answer! Also, I would recommend that you have a clean working copy (all changes committed or create new branch). This way, you can always revert back if the update causes any problems. Version control #ftw! – Kiliman Mar 09 '15 at 14:36
  • 3
    Agree with the answer here. To supplement, also keep in mind the risk of not keeping the nugets up to date. Depending on the number and complexity of the packages you might end up in technical dept if never updating. For instance, not long ago Xamarin.Forms nuget 4.5 included a reference to a deprecated iOS component, and Apple announced rejection of new releases containing this deprecated component. In Xamarin.Forms 4.6 this reference was removed, hence fixing the deprecation problem. – Vering Nov 13 '20 at 09:54
1

Few tips to decide package update strategy:

  • Don't run production application on a deprecated (not-maintained) package version. Upgrade to a maintained version at bare minimum if unable to upgrade to latest.
  • Don't run production application on a pre-release (not-stable) package version. Upgrade to a stable maintained version.
  • While upgrading by a major version, read publisher's release notes to understand the implication backward-compatibility from application context. This will help put a better estimate on development and testing efforts.
Debashish Sarkar
  • 47
  • 5