how about: 1. we force versions of dependencies in commons-parent 2. we make every commons repo use commons-parent as parent. 3. we make sure no other repos forces versions of dependencies; all of the versions number shall be inherited from commons-parent 4. we upgrade versions in commons-parent every several months.
Bernd Eckenfels <e...@zusammenkunft.net> 于2020年7月24日周五 下午9:49写道： > 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 > >
