[avi_vallarapu]

I went through this project before.

For some applications it might be of great use but for a vast and complex applications architecture, the libyear metric might only oversimplify the complexity of dependency management,compatibility issues, updates and security patches, etc

I noticed that it focuses only on the age of dependencies without considering other factors like the how critical is the update, and how stable it is, and the improvements in newer versions, etc.

[liampulles]

It's a tradeoff between having a simple and easily quantifiable measure vs a more subjective, more complex and more accurate measure.

Libyear seems like a decent starting measure if there is no appetite for something more in-depth, IMO and YMMV.

[KingMob]

> Libyear seems like a decent starting measure if there is no appetite for something more in-depth

Maybe, but couldn't measuring, and thus reacting to, a bad measure be worse than doing nothing?

[verve_rat]

Sure, it's almost like you need to exercise judgement when selecting metrics and planning your work.

[KingMob]

Right, but that means it's not a decent starting measure.

To me, "decent starting measure if there is no appetite for something more in-depth" sounds like "just drop it in, it's enough to get started, we'll figure out the rest later", but that could be temporarily harmful.

Exercising judgment is the opposite of that, no? Then you're going into depth.

[Raed667]

At a previous company we had this big web-app (filterable) matrix which listed each project dependency, but the neat thing was that you can tag dependencies to add weight and importance.

Initially i thought it would need to be more complex, but but it was more than enough.