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*
