How Far Behind Are Your Dependencies?

The world keeps turning and when you do not actively spend time to update the dependencies of your projects, you will fall behind. First one minor version, then another and before you know, there are a few new major versions released and your project is full of security risks.

We all know that his happens and even when we try to keep everything up to date, sooner or later we fall behind. We cannot give up, then that makes it even worse. There is only one way forward: Update your projects. But where should we start? And how bad is it now?

Where you start depends on a long list of criteria. You know your project better than I do and only you can make an assessment on what dependencies need to be updated ASAP.

The other question is a lot simpler. “How bad is it?” can be answered with a single number and even better, you do not need to do much work to get that information. There is a little tool called libyear from Steve Desmond that will answer this question. You can install it by typing this command into your command line tool:

This installs libyear into your system (and not a specific project). To figure out how many years your dependencies are behind, you can go to the folder that contains one of your projects and run dotnet libyear:

In my case I have 2 projects using DbUp. The first one is up to date, while the second one uses version 3.3.4 of DbUp, that was released 2.6 years before the current version. This tool calculates how old each of your dependencies is and sums them up. At the end you get one number, the number of years you are behind. Bigger projects with many more dependencies will quickly reach a value with two, three or even four digits; therefore, don’t be surprised when it looks a lot worse with your projects.

I like this metric because it gives you a quick and unmistakable answer on how far behind your project is. You can argue about its scientific merit, or you can update your dependencies. I suggest we postpone this discussion until we figured out a way that prevents our dependencies from falling so far behind.

In my example one of the projects uses .Net Core, while the other uses the .Net Full Framework. Mixing those project formats is not a problem. There are libyear implementations for Ruby (Bundler) and JavaScript (npm) which allows you to use this metric outside of the .Net world as well.

I would love to hear from your experiences with this little tool and how it helps you to update your dependencies. At how many years behind do you act? And does it help you to keep up to date?