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* >
