Hacker News Reader

Comment by IanCal | Hacker News Reader

Isn't "we are 5 major releases behind" more obvious that "two libyears".

> If your system has a one year old dependency and a three year old dependency, then your whole system is four libyears old.

How far down the tree do we go? Either fully, which means that one project with 365 one day old dependencies is 1 libyear old. Or not at all, as the rails example suggests, in which case if I have a wrapper around rails that I bump to an old rails version, anyone using my wrapper would have older rails but a fewer libyears?

There is no single answer to all of this, because it's too complex to boil down to a single number. But I think it's a bit odd to introduce a whole new thing that doesn't measure at all what's changed.

View on HN

I had the same immediate reaction that you did, but the key here is that the age of dependencies is not absolute but calculated against the latest release. So a one-day-old dependency with no succeeding version is 0 libyears old, not 1/365.24. Likewise for a decade-old release, if it is in fact the latest release.

It’s about the time delta between the used version and the latest available version.

But this still means that you're either on the latest version or 39 libyears behind (if you count all dependencies of dependencies of dependencies...)

I think each dependency is only counted once, even if it’s recursively included many times.

Adding transitive dependencies might be tricker, because then you can't tell what of your direct dependencies to upgrade.

It might be more useful to assign each direct dependency's transitives to it, and then you can do maths to figure out whether updating a direct dependency actually has an effect (e.g. 2 directs both with a 50 lib year dependency aren't worth upgrading unless you upgrade both of them.)

> There is no single answer to all of this, because it's too complex to boil down to a single number.

Having a single number that is a rough measure is still useful, though perhaps a (weighted?) average would be more useful.

Anyway, I just downloaded the Python tool (called "libyear" on PyPI) and ran it to quite quickly find three dependencies on my project that were over 2 years behind. That was helpful and I would use it again.

They're tracking different related things. I run a startup in this space and we track: aggregate libyear of your direct dependencies; total # of direct dependencies with libyear > 2; # of direct dependencies at least one major version behind; dependencies that have been abandoned by the maintainer.

I think the top-line aggregate libyear number is helpful to monitor over time to get a general sense of the slope of your technical debt. If the number is trending upwards then your situation is getting worse and you're increasing the chance you find yourself in an emergency (i.e., a CVE comes out and you're on an unsupported release line and need to go up major versions to take the patch).

Tracking total # of major versions behind gets at the same thing but it's less informative. If you're on v1 of some package that has a v2 but is actively releasing patches for the v1 line that should be a lower priority upgrade than some other package where your v1 line hasn't had a release in 5 years.

It feels like it just has so many weird edge cases. A stable 2.3 branch that hasn't changed while the 1.2 branch has major security issues punishes you for not using the 1.x version.

A regularly updated 1.x branch for docs/security looks like you're doing fine even though the project is on 3.x and deprecating soon.

Perhaps as a vague guide to point to potential issues, sure.

I think it only counts direct dependencies.

So that means that the way to game this would be to create a wrapper project (e.g. called "external_deps") for all of my dependencies, and then have my actual project depend on that one. So I'm externalizing all of my tech debt onto external_deps and as long as I never make a new release of that, my main project will always be 0 libyears old.

Even if you could, why would you? It'd be the same to, say, fork a projectX to myprojectX and say you're at the latest version.

You are the one that has an advantage to know you're behind, not someone else.

Look up Goodhart's Law.

Wouldn't it be easier to "game" the tool by just not using it?

> So that means that the way to game this would be to create a wrapper project (e.g. called "external_deps") for all of my dependencies, and then have my actual project depend on that one

No, you can't resort to chicanery to manipulate your metric.

In this case, the libraries you want to use become transitive dependencies, but if your code uses those transitive dependencies, then your project still depends on them.

Then the rails example on the main page is wrong.

People already do that with vendorizing, too. It was noted the other week on HN of someone "collateralizing" their tech debt by vendorizing a dependency to remove CVE/deprecation/obsolescence warnings for a Rust dependency with no update path: https://news.ycombinator.com/item?id=39827645

A metric like this can't keep you honest (just about no matter how you design it, people will find loopholes), but it can help honest people document their needs.

What's nice about the "libyear" concept is that it exposes the cost of indiscriminately pulling in 3rd party libraries.

IE, it discourages someone from sucking in a library just to use one tiny function that they could recreate in 10-15 minutes.

That sounds entirely orthogonal to the goal, which isn't a good thing for a metric.

Reply on news.ycombinator.com