This also wrongly assumes that newer is better.

For example, CLDR changed the UK abbreviation for September from "Sep" to "Sept" and broke a lot of code as libraries used newer versions of the data https://unicode-org.atlassian.net/browse/CLDR-14412

If you're on a 3 year old version of the library because the library introduced a change which you will never be able to adopt so you're forever stuck on the 3 year old version, you're in a much worse position than if you're just 3 versions behind because you haven't taken the time to upgrade yet. As such, libyears become an optimistic measure of badness in that situation.

What if the library new features aren't useful to your project and do not correct any bug you might hit in your use case?

If you're going to audit your dependencies sufficiently to know that then you don't need a tool like this anyway?

A tool like that won't replace auditing dependencies.

The total age of dependencies tell you nothing useful.

Nor did I claim it would. If you are auditing your dependencies like that then you don't need it, I said, as in it's not going to give you any extra information.

If you're not, and very many people are not, then total age of dependencies is a decent low-effort approximation for the probability of bug fixes affecting parts of dependencies that you're using.

What if security fixes are useful to your project

I count security fixes with "bugs that you would hit in your use case".

I don't care about CVEs that only affect functions my app do not use.

Why are you in a worse position?

That depends on the changes to the library since, and how and where the library is used.

Suppose I regularly generate a CSV file, all ASCII, where all the rows are integers or fixed precision numbers. I have a ten year old CSV library that processes that file, and has worked without any problem for ten years.

I have no interest in updating the library. Updates can introduce downtime, but provide no improvement. In fact, they introduce a slight performance hit because of new features and that I don't need. There is also the risk that the updates will introduce bugs, and then I'll have to spend time diagnosing the bug, and coming up with a fix.

Now let me reverse this: suppose there are two libraries to do the same task, A and B. They don't have the same features, but for your use case, they are both easy to use and do exactly what you need.

A was first released in the 1980s and was last updated five years ago. It's still maintained and is available in most Linux distributions.

B was first released three years ago and has had 20 updates since, 18 of which included fixes for security issues that don't affect A. (The website for A is regularly updated to indicate that it has been tested and these issues do not affect t.)

Are you better off using A or B?

> Why are you in a worse position?

Because, in general, as you drift behind, the friction of upgrading will increase.

You might not need to update today, but you're not in control of external events that may force your hand (sudden critical security vulns).

> Are you better off using A or B?

In this contrived example, it depends.

I see the overall point as not seeing every dependencies as things that need upgrade.

Any library that is effectively a dataset could fall into this as well: if you want to freeze your environment at a specific reference point and only update the actual moving parts, the libyear measurement won't be for you.

This reminds me of interface softwares that keep old version of some libraries to emulate the original behavior, butnin a controlled and isolated way.

On the other hand, it was only somewhat recently that CLDR acknowledged that languages with noun inflection exist, so it’s kind of a wash. E.g. in Russian, Ukrainian, and Belarusian (at least) you use the nominative of the month’s name in May 2024, but the genitive in 9 May 2024, etc., rendering most older allegedly-localized software that used a generic list of month names ungrammatical.

You might, but I didn't.

My immediate thought looking at this number was not that it should be minimized but that there ought to be a sweet spot range and a number below which it probably shouldn't go and a number above which it shouldn't go.

It's always context-dependent. Take Lisp languages. For Common Lisp, when I see a library that was last released or updated 10 years ago, I'm thinking it's probably as feature-complete as it's ever going to be, and otherwise perfectly fine. Same in case of Emacs Lisp? I'm thinking generations out of date, and has a solid chance of not working anymore. Here, it's a difference between a battle-tested, standardized (ANSI/ISO) platform (CL), vs. fast-evolving one (Emacs).

What was the reasoning behind that change ?

I've tried out some of the libraries, and it looks like they do calculate the difference between the installed version and the last (stable) release. If a dependency hasn't seen a release in ten years, those ten years don't count against the dependency drift. This is exactly what I would want.

However, they only check openly accessible (i.e. OSS) dependencies. If one of those hasn't seen a release in ten years, I would look for an alternative.

Agreed. If the dependency is under active development then it should be only counted as being behind if there is a newer version released for that dependency. The libyear should be calculated as "latest version's release date" - "currently used version's release date".

What complicates this is deciding whether the dependency is under active development or not. If its EOL'd then you still want libyear to accumulate, even if you use the latest released version. I guess comparing to an end-of-life date then would make sense, but it's probably harder keep track of.

If a project is not under active development it may just be "done". How many minor version bumps per year does left-pad need?

Do you write your own JSON parser?

Is there a JSON parser library that is not under active development?

Agreed. Freshness is not a good metric to quantify the quality of a library.

Anecdotally the Python tool seemed to indicate for me a 0 for a dependency which was up to date (but hadn't been updated in a good year at the very least).

A more accurate (but more unwieldy to measure) metric would be to count the lines of code that have been changed since the version used and the most recent stable version. (I think this is what commenter amelius implied?) It wouldn't quite capture the nature changes made, but it would very much uncouple from the quite unwieldy assumption that libraries are all developed at the exact same pace.

I don't think that lines of code is a good metric here. A few lines of code can fix a major security issue in parts of a dependency that you actually use, while thousands of lines of code can just add new features that you are not using anyway, otherwise you would have upgraded already.

Well, it's up to you to interpret the libyears how you like. It doesn't have to be that more libyears is worse, but it will mean that you're missing X libyears of security updates (and also X libyears of potential new bugs).

Well, no you can't. Adding them together implicitly affirms that libyears from different dependencies are equivalent.

Yes, that's the point of the metric. The observation that libyear is a dimension, libyears are additive.

If you value some library years more, and some less, then weight the sum.

It's like saying there is no point of natural numbers, because when you count apples, some apples might be rotten.

It's saying you can't add different units together.

Yes it does. And you can say "this project has more libyears, so it's more mature".

That really doesn't follow. A barely maintained mess of a personal project running for 10 years is not more mature than a 7 year project heavily developed and released by a high quality team, with 3 years of stability in the main API and in use around the world.

Are you saying that libyears is a pointless metric? That's what your comment implies.

Broadly, yes.