5 ms·
Libyear – a simple measure of software dependency freshness
- edoceo 6y agoNeat. I know what tool I'm evaluating this FeatureFriday.
- ethanwillis 6y agoTime 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
- jdanil 6y ago> 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-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.
- sooheon 6y ago> 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.
- mgkimsal 6y agoby 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?
- Vinnl 6y agoI 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.
- ethanwillis 6y agoThis 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.
- sigmonsays 6y agohow is age a good factor for a good library?
- closeparen 6y agoStale 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.
- m_eiman 6y agoA better measure would be "(security) issues reported since the version you're using", I suppose.
- DEADBEEFC0FFEE 6y agoOnly 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.
- unhammer 6y ago> 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=160,-67,385 https://ericbouwers.github.io/papers/icse15.pdf#page=9&zoom=...
- kimburgess 6y agoPaper that inspired this: https://ericbouwers.github.io/papers/icse15.pdf https://ericbouwers.github.io/papers/icse15.pdf (linked by the author in the README's)
- m_eiman 6y agoI how many libyears behind a one-month old "simple SPA" npm-based javascript project is.
- amelius 6y agoAre software metrics still a thing?
- NohatCoder 6y agoYes. Are software metrics still useless? Also yes.