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 incompatible.
The proposal seems reasonable. Anthony > On Aug 13, 2019, at 9:47 AM, Jacob Barrett <jbarr...@pivotal.io> wrote: > > 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 could > just open a ticket that requests that all dependencies be updated, then > anyone could jump on that ticket. > > -Jake > > >> On Aug 13, 2019, at 9:38 AM, Aaron Lindsey <alind...@pivotal.io> wrote: >> >> 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 currently >> determine our major release cycle? Would we know at the time of a GA release >> whether the next release would be a major or minor release? >> >> - Aaron >> >>> On Aug 13, 2019, at 9:22 AM, Nicholas Vallely <nvall...@pivotal.io> wrote: >>> >>> 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 dependencies. As far as I >>> know, we do not have a process to keep dependencies up to date or regularly >>> scheduled updates to them. Currently, I believe this is handled ad-hoc >>> which hasn't necessarily caused any major issues but could. >>> Anti-GoalsSolution >>> >>> *Directly after GA release of Geode minor version:* >>> The release manager for the most recently released version of Geode would >>> review any dependencies in the Geode project (presumably this will/could be >>> automated). >>> >>> - For a minor release, only minor version dependency updates should be >>> considered >>> - For a major release, major versions should be considered >>> >>> The release manager would submit a PR to update dependencies and then the >>> community should pitch in to tackle any subsequent issues that arise from >>> the updating of dependencies. *Note the first time this happens maybe >>> painful* >>> >>> *In-between releases:* >>> We keep doing what we are doing: >>> >>> - Ad-hoc dependency updates as necessary >>> >>> *When a new release manager is chosen:* >>> The release manager would send out an email as the last call for dependency >>> updates that would coincide with a proposed release branch cut date. This >>> would give everyone a reminder that if they need to update a dependency >>> prior to the release there is limited time left in order to do so. >>> Changes and Additions to Public Interfaces >>> >>> *n/a* >>> Performance Impact >>> >>> *Potentially a new version of a dependency could cause a performance impact >>> and we should run a performance test suite on the recently released version >>> vs the updated dependency version* >>> Backwards Compatibility and Upgrade Path >>> >>> *In a minor release, minor version dependency updates shouldn't cause >>> compatibility issues.* >>> Prior Art >>> >>> *What would be the alternatives to the proposed solution? What would happen >>> if we don’t solve the problem? Why should this proposal be preferred?* >>> >>> *If we continue to do this ad-hoc, there is a greater likelihood of CVE's >>> or mismatching versions of conflicts between Geode and dependent projects.* >>> >>> >>> *Nick* >> >
