3 ms·

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 lib

by 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.
- prmoustache 2y ago
  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?
  - OJFord 2y ago
    If you're going to audit your dependencies sufficiently to know that then you don't need a tool like this anyway?
    - rrwo 2y ago
      A tool like that won't replace auditing dependencies. The total age of dependencies tell you nothing useful.
      - OJFord 2y ago
        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.
  - mort96 2y ago
    What if security fixes are useful to your project
    - prmoustache 2y ago
      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.
- rrwo 2y ago
  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?
mananaysiempre 2y ago
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.

by rrwo 2y ago

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.

prmoustache 2y ago
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?
- OJFord 2y ago
  If you're going to audit your dependencies sufficiently to know that then you don't need a tool like this anyway?
  - rrwo 2y ago
    A tool like that won't replace auditing dependencies. The total age of dependencies tell you nothing useful.
    - OJFord 2y ago
      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.
- mort96 2y ago
  What if security fixes are useful to your project
  - prmoustache 2y ago
    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.
rrwo 2y ago
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?

mananaysiempre 2y ago

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.