19 ms·
libyear assumes that constant development happens all the time in a library and software has to change and grow constantly. There are some libraries that are ju
by agilob 2y ago
libyear assumes that constant development happens all the time in a library and software has to change and grow constantly. There are some libraries that are just mature and doesn't need to change. 5.0.1 could be released 5 years ago, and 5.0.1 today with just changes to docs. It doesn't mean that it took 5 libyears to develop and release the new version. This is the type of thinking that attackers used in xz trying to pressure original author to add more official maintainers, because he wasn't merging and updating code fast enough. "You're not merging and releasing our code fast enough, therefore you're doing bad job".
What would be other measures that could be similarly useful? Lines of code or story points? Maybe even a number of tests added?
- quassy 2y agoThat is an argument for libyears, not against it. If they only updated the docs, why didn't you upgrade already? If anything, projects using stable libraries like this could very easily reach 0 libyears, because there are no breaking changes when upgrading.
- agilob 2y agoIt's for and against at the same time. Depends on your software upgrade roadmap. I think that's just a silly number, that us correct and incorrect at the same time, but probably good enough on a large scale, just like story points.