Geode dependency update process

To be Reviewed By: August 28th, 2019

Authors: Nick Vallely

Status: Draft Draft | Discussion | Active | Dropped | Superseded | Onhold

Superseded by: N/A

Related: N/A

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

Solution

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).

...

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.

FAQ

Answers to questions you’ve commonly been asked after requesting comments for this proposal.

Errata

What are minor adjustments that had to be made to the proposal since it was approved?