[semanser]

As a person who works on automated dependency updates (depshub.com), the libyear indicator is often not very useful. There are several other indicators to consider, such as release frequency, update type (major/minor/patch), the dependency's criticality for your project, etc.

Instead of solely focusing on reducing the libyear for your projects, a better approach is to minimize the steps needed to keep your project reasonably up to date. For instance, think about managing 20 PRs weekly to update various package.json packages versus 1 PR for critical dependencies when necessary.

It's important to note that updating dependencies is not a consistent task that can be done at the same pace all the time. Expect varying update volumes and complexities that may need attention at different times. Setting a fixed configuration for, let's say, 10 updates per week may not be effective, as it could lead to dealing with unnecessary updates regularly (e.g., aws-cli, which has almost daily releases).

Finding the right balance between keeping your project up to date and spending too much time on dealing with dependencies is the hardest part here that doesn't have a 100% right answer yet.

[mikepurvis]

I've been doing this work for a while and been pushing my org to move from updating the "base layer" every 2-4 years (Ubuntu LTS versions) down to every six months (each NixOS release).

I think one thing I've increasingly found is that it's important to set up the infrastructure for parallel building— it's not realistic to have a flag day twice a year, and it's not realistic to try to test everything first "on a branch". If you can have a transitional period of a few weeks where the product outputs (containers, dev environments, whatever) are consistently available in both the old and new flavour, then you can invite people to try the updated thing, while still having an escape lane to keep using the older thing if stuff turns out to be broken in a way that's beyond their capacity to correct in the moment.

[Crier1002]

I'm interested in knowing more about how companies typically gauge the freshness of their codebase dependencies. putting all the nuances/details aside, i think we can all agree that having a codebase with most dependencies that are over 8 years old is a pretty clear indication that it's way overdue for an update, right?

i was thinking, would it be helpful to keep track of how far behind each dependency is in terms of minor, patch, and major updates? but this seems a bit too complex to explain to the management. i'm trying to figure out the best way to explain this to management so they understand why it's important to stay current. any ideas on how we can measure improvements? maybe we should agree on a few key factors to track our progress and see if we're getting better or worse.

[semanser]

> I was thinking, would it be helpful to keep track of how far behind each dependency is in terms of minor, patch, and major updates?

This is exactly what I've added for depshub.com, and people seem to like it a lot. It just gives you better visibility across all of your connected repositories about what the current status of each dependency is and how the major vs. minor vs. patch ratio changes over time. While it's still a naive metric, it's the easiest to understand and visualize - and as a result, the one that is used the most.

> Any ideas on how we can measure improvements?

- Quantitative: Spend as little amount of time as possible on trying to keep everything relatively up to date (hours/month) - Qualitative: not having any CVE issues, not having major updates for core libraries and tools.

[fragmede]

if it ain't broke