Time isn't the best proxy for software quality. What is the point of freshness if freshness doesn't really mean correct? It could very well be there are older alternative libs that are better
> It could very well be there are older alternative libs that are better
The libyear metric doesn't count when the dependency was last updated by the maintainer. Its a diff of the version you're currently using compared to the latest release, to tell you how out of date your current dependencies are.
Its pretty much a dependency drift fitness function (https://www.thoughtworks.com/radar/techniques/dependency-dri...). Some of the variants on this page do support alternate metrics, like the ruby and node versions which can calculate number of releases behind rather than time.
> The libyear metric doesn't count when the dependency was last updated by the maintainer. Its a diff of the version you're currently using compared to the latest release
Somehow this made it all click for me, when the landing page didn't. Site made it seem like the measure rewards absolute value recency.
edit:
offending sentence is the following:
> If your system has two dependencies, the first one year old, the second three, then your system is four libyears out-of-date.
if my main project is using a core framework version from, say, 2019, and all the installed dependencies are from 2018/2019, the 'libyear' calculations are all relative to that 2019 base date, vs whatever 'now' is?
I think if you're using a framework version from 2018, and that framework released a new version in 2019, that framework would add 1 libyear. However, if there hadn't been a new release of that framework, you'd be up-to-date and hence it contributes 0 to your libyear score.
Repeat that calculation for your other dependencies, relative to their latest release date.
> The reported security vulnerabilities study shows that sys-tems with a low dependency freshness score are more than four times as likely to contain security issues in these depen-dencies. This confirmed the relationship between the security quality factor of a system and its dependency freshness rating, although no claims of causation could be made
Stale libraries are a risk factor for publicly disclosed vulnerabilities (likely more exploitable than the underlying OS, since library code is closer to user input). Also for diamond dependency conflicts when you try to bring in or upgrade a different library.
