[DISCUSS] Dependency update process (split from vote)

[Alexander Murmann <am...@pivotal.io>]

Splitting this from the vote thread.

Pulkit had suggested the possibility to try updating dependencies as part
of a regularly run job. That is very similar to the process proposed by
Netflix's dependency lock plugin
<https://github.com/nebula-plugins/gradle-dependency-lock-plugin/wiki/General-Use-Pattern>
.

I see lots of value in a dependency management tool that captures and uses
more information than we currently have. I'd like to see the following
information captured:

   1. What is a known good set of dependencies?
   2. Which dependencies cannot be updated safely?

We currently have 1. in the versions properties but not 2. Having both
pieces of information would allow for a process that updates all
dependencies that are not known to need manual changes in order to update,
runs tests and if successful locks down dependencies so that I can easily
answer 1. with latest versions.

This would cut down on manual effort and get us newer versions and their
security patches for practically free for many libraries.

There are of course lots of details that would need to be figured out.

Thoughts?

Re: [DISCUSS] Dependency update process (split from vote)

[Bruce Schuchardt <bs...@pivotal.io>]

The jgroups dependency must be manually changed and cannot, at this 
point, be updated.


On 4/5/18 10:35 AM, Alexander Murmann wrote:
> Splitting this from the vote thread.
>
> Pulkit had suggested the possibility to try updating dependencies as part
> of a regularly run job. That is very similar to the process proposed by
> Netflix's dependency lock plugin
> <https://github.com/nebula-plugins/gradle-dependency-lock-plugin/wiki/General-Use-Pattern>
> .
>
> I see lots of value in a dependency management tool that captures and uses
> more information than we currently have. I'd like to see the following
> information captured:
>
>     1. What is a known good set of dependencies?
>     2. Which dependencies cannot be updated safely?
>
> We currently have 1. in the versions properties but not 2. Having both
> pieces of information would allow for a process that updates all
> dependencies that are not known to need manual changes in order to update,
> runs tests and if successful locks down dependencies so that I can easily
> answer 1. with latest versions.
>
> This would cut down on manual effort and get us newer versions and their
> security patches for practically free for many libraries.
>
> There are of course lots of details that would need to be figured out.
>
> Thoughts?
>