libyear

A simple measure of software dependency freshness. It is a single number telling you how up-to-date your dependencies are.

Example

Rails 5.0.0 (June 2016) is 1 libyear behind 5.1.2 (June 2017).

Simpler is Better

There are more nuanced ways to calculate dependency freshness. This approach is simple. You can explain this calculation in 30s.

Download / Tools

• dotnet (NuGet) - dotnet-libyear
• js - libyear (GitHub Action: libyear-node-action)
• php (composer) - php-libyear
• python (PyPI) - libyear
• python - piprot (since 2013)
• ruby (bundler) - libyear-bundler
• java (Gradle) - libyear-gradle-plugin
• java (Maven) - libyear-maven-plugin
• scala (Maven and SBT) - release
• your favorite - contributions welcome

Better cartoon welcome :)

Example 2

If your system has a one year old dependency and a three year old dependency, then your whole system is four libyears old.

A Healthy App

At Singlebrook we try to keep our client’s apps below 10 libyears. We regularly rescue projects that are over 100 libyears behind.

Etymology

"lib" is short for "library", the most common form of dependency.

Other Measurements

libyear-bundler implements some of the other metrics described by (Bouwers, Eekelen, Visser, 2015).

The --versions flag provides a metric for an installed dependency’s freshness relative to the newest release’s major, minor, and patch versions. Of course, this is most useful for dependencies that follow a consistent versioning scheme such as semver.

The --releases flag provides a metric for the number of releases between an installed version of dependency and the newest released version of the dependency.

Each metric has it’s own advantages and disadvantages, and all quantify the maintenance burden for an app. Taken together, they can help prioritize maintenance for an inherited app, or help maintain a baseline level of dependency freshness for an ongoing project.