Hello, When it comes to dependencies wie have both problems: if we upgrade dependencies to aggressively (or if we don't test with older dependencies) then users have the problem that they might not easily be able to upgrade to a new commons version since the required new dependency version might conflict with other (thirdparty) users of that dependency.
On the other hand if we not continuously update external dependencies we might miss out on their new features, performance and fixes. In addition we might fall behind and have the to do painful Big Bang Upgrades. Also when our transitive dependencies are outdated and contain bugs (or compliance violations due to old code) some customers might not be happy. So there is a middle ground to be found, which unfortunately collides with the current limited effort maintenance of some of the components: - we should define a minimum baseline version of dependencies and runtimes and on each release we check if we still meet them. When we raise the baseline we should ship a new minor (or even major) version. Also we might want to ship security fixes only as a micro update (I.e. not requiring major updates besides the affected code) - we should regularly test against latest dependency versions (at least within the same minor branch). Dependbot could be a help here, however I do find it a bit annoying and not needed as I would run the dependency report if I have the need to find me something to work on. Gruss Bend -- http://bernd.eckenfels.net ________________________________ Von: Stefan Bodewig <bode...@apache.org> Gesendet: Friday, July 24, 2020 3:36:36 PM An: Commons Developers List <dev@commons.apache.org> Betreff: Re: [all] When to update dependencies? On 2020-07-24, Gary Gregory wrote: > Now back to our code depending on other dependencies. My view is that there > are bugs, you just have not hit them. If I find one in a dependency and it > gets fixed, it's going to mean a new version of that dependency. This either is "we hit a bug that affects us" - where I already say this is a reason to upgrade for me - or "the user hits a bug" - in which case I prefer to let the user update the buggy dependency. I don't want to force the user to update because they might be affected by bugs. And of course we both know that newer versions not only fix bugs, they introduce new ones as well. > Furthermore, when I look online for Javadoc and examples, if I use a > current jar version, then my odds are better that I can implement what I > find online. https://javadoc.io/ or similar services? > I view it as simpler and safer to update from a "near" dependency than > letting a dependency acquire "bit rot" and upgrade later, especially > if an update means making adjustments. I want to make smaller > increments of adjustment rather than a larger set. Just like I prefer > to RERO instead of big bangs for releasing Commons components. I fully agree with you if nobody else depends on my stuff. I.e. I'm working on an application rather than a library. When working on a library I really want the user to be and stay in control. > Another way to look at this is to look at a large software stack: If every > library developer never updates dependencies, then your application, > through transitive dependencies will end up depending (virtually) on many > versions of the each library, which is much more likely to create jar hell > and other problems than the other edge case where everyone uses the latest > version (or a fixed version.) You are just hitting home on Stefan's almost 20 year old impression that automatic transitive dependency resolution is a BAD IDEA. ;-) I fully expect you (all of you) to ignore that last remark. > From a hand-waving-talking-over-beers-more-FOSS-y philosophical-POV, I'd > like to think that by eating our own current Apache dog food as well as > other FOSS dog food, we all help each other make our software better. We might help the developers of our dependencies but I'm afraid we are hurting our dependees - and I tend to care more for the latter. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
