Before
After
A simple measure of software dependency freshness. It is a single number telling you how up-to-date your dependencies are.
For example, a rails 5.0.0 dependency (released June 30, 2016) is roughly 1 libyear behind the 5.1.2 version (released June 26, 2017).
There are obviously more nuanced ways to calculate dependency freshness. The advantage of this approach is its simplicity. You will be able to explain this calculation to your colleagues in about 30s.
If your system has two dependencies, the first one year old, the second three, then your system is four libyears out-of-date.
At Singlebrook we try to keep our client’s apps below 10 libyears. We regularly rescue projects that are over 100 libyears behind.
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.
"lib" is short for "library", the most common form of dependency.