Hello, We can certainly put some dependencies in commons parent dependency management (and the plugins like we used to), but for a lot of stuff I don't think we will be able to find a common ground, and it will be quite painful if projects no longer can update commons parent without major testing and integration work (plus things like jackrabbit which is only(?) used in vfs might really be overhead to maintain that in a parent)
-- http://bernd.eckenfels.net ________________________________ Von: Xeno Amess <xenoam...@gmail.com> Gesendet: Friday, July 24, 2020 3:53:18 PM An: Commons Developers List <dev@commons.apache.org> Betreff: Re: [all] When to update dependencies? 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 > >
