Libyear – a simple measure of software dependency freshness | Hacker News Reader

Libyear – a simple measure of software dependency freshness

libyear.com

66 pointsjdanil16 comments

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.

by way of example...

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.

This seems a good bit better than my understanding of how it worked. I still don't think I could advocate for it, but nonetheless it is interesting.

Paper that inspired this: https://ericbouwers.github.io/papers/icse15.pdf

(linked by the author in the README's)

I how many libyears behind a one-month old "simple SPA" npm-based javascript project is.

Neat. I know what tool I'm evaluating this FeatureFriday.

how is age a good factor for a good library?

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.

A better measure would be "(security) issues reported since the version you're using", I suppose.

Only if you think all the security issues have been found in all the libs.

Lesser known libs can be riddled with vulns that nobody has found.

> 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

https://ericbouwers.github.io/papers/icse15.pdf#page=9&zoom=...

Are software metrics still a thing?

Yes.

Are software metrics still useless?

Also yes.

Reply on news.ycombinator.com