+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, proactively, as much as possible.
More often than not, they fix the very problems (bugs, CVEs, performance issues) they introduced in the first place while also provide enhancements. The bottom-line is, any project with transitive dependencies is responsible for "managing" those dependencies. -j On Wed, Aug 14, 2019 at 6:43 AM Anthony Baker <aba...@pivotal.io> wrote: > 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* > >> > > > > -- -John john.blum10101 (skype)
