They've succeeded in creating a single metric that's easy to calculate, but IMHO, it fails to be very useful for common use cases.
Basically, it just uses the difference between the date the library version you are using was released and the current date if there's a newer release available.
Eg, if you are using a library that has been unchanged at 1.0.0 for the last 10 years, you'll be 0 libyears behind that whole time. Then one day, the developers of that library release 1.0.1. One minute after that hits the package repositories, you are immediately 10 libyears behind.
This makes it pretty useless as a metric for tracking how outdated an application really is. Eg, as an ops/SRE/security person, I'd want to be able to run this on a product team's code and have a single number that tells me whether they're reasonably up to date or seem to be ignoring their dependencies and letting technical debt pile up. A team could've been on the ball, keeping every dependency updated daily for years, but if I use libyear to evaluate them right after that that 10 year old dependency updates, it's going to look like they've been negligent.
I'm the developer of depshub.com (for automated dependency updates using AI) and even though a single metric isn't valuable, having any sort of indicators and metrics is very useful when you have more than one repository. Being able to quickly see if your repositories are getting better or worse over time helps to understand when the dependency updates should be prioritized (if so) in the first place. There are a few core metrics that I've built (major vs minor vs patch ratio, security updates, etc.) into the product, and it's one of the most used features up to date.
Comments
They've succeeded in creating a single metric that's easy to calculate, but IMHO, it fails to be very useful for common use cases.
Basically, it just uses the difference between the date the library version you are using was released and the current date if there's a newer release available.
Eg, if you are using a library that has been unchanged at 1.0.0 for the last 10 years, you'll be 0 libyears behind that whole time. Then one day, the developers of that library release 1.0.1. One minute after that hits the package repositories, you are immediately 10 libyears behind.
This makes it pretty useless as a metric for tracking how outdated an application really is. Eg, as an ops/SRE/security person, I'd want to be able to run this on a product team's code and have a single number that tells me whether they're reasonably up to date or seem to be ignoring their dependencies and letting technical debt pile up. A team could've been on the ball, keeping every dependency updated daily for years, but if I use libyear to evaluate them right after that that 10 year old dependency updates, it's going to look like they've been negligent.
I have an open issue on the Python implementation (which ironically(?) hasn't had any commits in three years) asking for clarification: https://github.com/nasirhjafri/libyear/issues/35
I'm the developer of depshub.com (for automated dependency updates using AI) and even though a single metric isn't valuable, having any sort of indicators and metrics is very useful when you have more than one repository. Being able to quickly see if your repositories are getting better or worse over time helps to understand when the dependency updates should be prioritized (if so) in the first place. There are a few core metrics that I've built (major vs minor vs patch ratio, security updates, etc.) into the product, and it's one of the most used features up to date.