+1 to Nick's proposal!
While you cannot always guarantee that a dependency for whatever version,
whether a new major, an updated minor or simply a patch release won't
introduce problems (regressions, performance issues, or worse, CVEs), it is
extremely important to keep dependencies up-to-date, pr
Usually there’s a bit of manual “art” to updating dependencies. You can’t
always rely on stuff not breaking in minor releases. The best example is
JUnitParams. Updating that breaks most of our tests since we use the test name
for many things like region names and the new format is incompatibl
We can simply update all dependencies to their latest as long as within a major
it doesn’t change the public API. We have tried to do this after releases,
though sometimes that PR languishes for a while. There is no formal process
though so formalizing it would be great. The release manager coul
I like the idea of proactively updating dependencies after each release. For
this to work we would have to know whether the next release will be a major or
minor release directly after each GA release (so that we can bump either major
or minor versions, as appropriate). How and when do we curren
https://cwiki.apache.org/confluence/display/GEODE/%5BDraft%5D+Geode+dependency+update+process
Here is the content of the wiki proposal above for a discussion:
Problem
We recently updated the dependencies for the log4j version used in Geode to
keep up with Spring Boot Data Geode's logging dependen
