6 ms·

Can't see this as being particularly useful. Libraries under active development will have larger more frequent releases (but small number of libyears out of dat

Can't see this as being particularly useful. Libraries under active development will have larger more frequent releases (but small number of libyears out of date) whereas mature software with only occasional bug fixes may be 10s of libyears out of date.

stavros 2y ago
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).
- edflsafoiewq 2y ago
  Well, no you can't. Adding them together implicitly affirms that libyears from different dependencies are equivalent.
  - stavros 2y ago
    Yes it does. And you can say "this project has more libyears, so it's more mature".
    - IanCal 2y ago
      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.
      - stavros 2y ago
        Are you saying that libyears is a pointless metric? That's what your comment implies.
        IanCal 2y ago
        Broadly, yes.
  - bmacho 2y ago
    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.
    - edflsafoiewq 2y ago
      It's saying you can't add different units together.
yunruse 2y ago
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.
- planede 2y ago
  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.
rrwo 2y ago
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 https://unicode-org.atlassian.net/browse/CLDR-14412
- pydry 2y ago
  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.
  - TeMPOraL 2y ago
    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).
- deleted 2y ago
  [deleted]
- BlueTemplar 2y ago
  What was the reasoning behind that change ?
- mort96 2y ago
  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.
planede 2y ago
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.
- __alexs 2y ago
  If a project is not under active development it may just be "done". How many minor version bumps per year does left-pad need?
  - planede 2y ago
    Maybe anything so simple that it can be considered "done" shouldn't really be an external dependency in the first place.
    - __alexs 2y ago
      Do you write your own JSON parser?
      - planede 2y ago
        Is there a JSON parser library that is not under active development?
Aldipower 2y ago
Agreed. Freshness is not a good metric to quantify the quality of a library.
fdw 2y ago
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.

stavros 2y ago

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).

edflsafoiewq 2y ago
Well, no you can't. Adding them together implicitly affirms that libyears from different dependencies are equivalent.
- stavros 2y ago
  Yes it does. And you can say "this project has more libyears, so it's more mature".
  - IanCal 2y ago
    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.
    - stavros 2y ago
      Are you saying that libyears is a pointless metric? That's what your comment implies.
      - IanCal 2y ago
        Broadly, yes.
- bmacho 2y ago
  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.
  - edflsafoiewq 2y ago
    It's saying you can't add different units together.

yunruse 2y ago

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.

planede 2y ago
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.

rrwo 2y ago

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 https://unicode-org.atlassian.net/browse/CLDR-14412

pydry 2y ago
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.
- TeMPOraL 2y ago
  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).
deleted 2y ago
[deleted]
BlueTemplar 2y ago
What was the reasoning behind that change ?
mort96 2y ago
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.

planede 2y ago

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.

__alexs 2y ago
If a project is not under active development it may just be "done". How many minor version bumps per year does left-pad need?
- planede 2y ago
  Maybe anything so simple that it can be considered "done" shouldn't really be an external dependency in the first place.
  - __alexs 2y ago
    Do you write your own JSON parser?
    - planede 2y ago
      Is there a JSON parser library that is not under active development?

Aldipower 2y ago

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

fdw 2y ago

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.