On 2020-07-24, Bernd Eckenfels wrote: > 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. I hear you. I'm not opposed to updating a dependency if we want to use new features. What I'd like to avoid is updating without a reason other than "there is a new version and it seems to work according to our tests". > 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) One problem with patch updates for security releases is the release vote will reveal a security update is in the making and the diff will be small enough to give away the details before the vote has passed. I may be paranoid. > - we should regularly test against latest dependency versions (at least > within the same minor branch). Apache Gump? What you describe sounds good, but "unfortunately collides with the current limited effort maintenance of some of the components". Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
