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.
But the examples don't actually make it totally clear (at least to me).
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).
OK, the relative difference is clear, but if I'm running libyear in my application which is using 5.0.0, is it going to report based on the age of 5.0.0 relative to today or relative to when 5.1.2 came out.
In 2023, if I had an app still using 5.0.0, would my libyear score be 7.13 or 6.14?
Here's a clearer scenario for me to get my question across:
I have an application with one library as a dependency which is at version 1.0.0 which was also released the same day. When I start, that's the only (or at least current) version of the dependency. Ie, there's nothing newer I can upgrade to. My expectation at this point is that my libyear score is "0" because I'm effectively fully up to date. There's nothing for me to upgrade.
One year goes by. The single dependency has not released an upgrade. Ie, I'm still as fully up to date as I could possibly be. My expectation again, is that my libyear score is still "0". Is that accurate, or is it now "1 year" because 1.0.0 of the dependency is a year old?
Later that day, the dependency releases version 2.0.0. I'm still on 1.0.0. A day later, is my libyear score "1 year" because my 1.0.0 dependency is a year out of date? Or is it "1 day" because the newer version has only been out for a day?
A week later, I'm still on 1.0.0, but dependency 3.0.0 is released. Am I now at "1 year and 1 week" or just at "1 week"?
My experience with other tools like piprot is that in that scenario it would go straight from "0" to "1 year" as soon as 2.0.0 is released, then back to "0" once I upgrade to the latest version.
Ideally though, the latter approach where the counter starts going up from zero once the new version is released is preferable. To me, that is a better representation of how far behind I am. This is especially important if I'm thinking about this as a metric that might be tracked and alerted on by an ops or security team when it crosses a threshold. Developers on the team might understand how the metric works, but from the outside, seeing a security-related metric go from 0 to 100 looks bad.
the README says
But the examples don't actually make it totally clear (at least to me).
OK, the relative difference is clear, but if I'm running libyear in my application which is using 5.0.0, is it going to report based on the age of 5.0.0 relative to today or relative to when 5.1.2 came out.
In 2023, if I had an app still using 5.0.0, would my libyear score be 7.13 or 6.14?
Here's a clearer scenario for me to get my question across:
My experience with other tools like
piprotis that in that scenario it would go straight from "0" to "1 year" as soon as 2.0.0 is released, then back to "0" once I upgrade to the latest version.Ideally though, the latter approach where the counter starts going up from zero once the new version is released is preferable. To me, that is a better representation of how far behind I am. This is especially important if I'm thinking about this as a metric that might be tracked and alerted on by an ops or security team when it crosses a threshold. Developers on the team might understand how the metric works, but from the outside, seeing a security-related metric go from 0 to 100 looks bad.