Ok, so you have a plugin that essentially prints out a report of dependencies and decides which ones are up to date. Here are my thoughts
- First, your patch is not correct and does not add the task you mentioned. It seems you didn't test it? - Upon testing this plugin, I found packages that match, exceed milestones, have later milestones (don't know the difference), and it failed to determine for some packages. I'm not sure what is useful about this information and how to apply it? I'm also not sure if this information is accurate? - Package updates is not something that can not be done easily and / or automated. It has to be done with care. - It seems like we are incurring the cost of pulling in more packages, more dependencies and more build time for no apparent immediate value? - The report does not distinguish between security updates and regular minor updates, which again does not provide a lot of value. - Finally, it seems that for a value to be derived from this plugin [1] it should automate the report and add more conditions and whatnot. Just putting it there doesn't do much on its own. So perhaps more care and thought should be put into this, and better analysis of value added should be done. And if anything, maybe we should consider _reducing_ our libraries in the first place, instead of adding more stuff into the pile. [1] https://github.com/ben-manes/gradle-versions-plugin/blob/master/examples/build.gradle On Tue, Jun 26, 2018 at 7:11 PM, Jacques Le Roux <[email protected]> wrote: > I thought my 1st message was clear enough. Let me try to phrase it better. > > In order for our users to have an easier and secure life, I suggest to have > this patch applied > > Index: build.gradle > =================================================================== > --- build.gradle (révision 1834418) > +++ build.gradle (copie de travail) > @@ -31,6 +31,7 @@ > classpath > 'at.bxm.gradleplugins:gradle-svntools-plugin:latest.release' > classpath 'org.asciidoctor:asciidoctor-gradle-plugin:1.5.7' > classpath 'org.asciidoctor:asciidoctorj-pdf:1.5.0-alpha.16' > + classpath 'com.github.ben-manes:gradle-versions-plugin:0.17.0' > } > } > apply plugin: 'java' > > And to create a Gradle task to use it. Actually just run > > ./gradlew dependencyUpdates -Drevision=release > > And of course to document it in our main README > > It would clarify how to keep libs updated to our users rather than having to > look for this in Jira or by themselves. > > What do you think (not only you Taher ;)) ? > > Jacques > > > > Le 26/06/2018 à 10:56, Taher Alkhateeb a écrit : >> >> I'm not sure I understand what you want to do exactly. Clarification would >> help >> >> On Tue, Jun 26, 2018 at 11:27 AM, Jacques Le Roux >> <[email protected]> wrote: >>> >>> Hi, >>> >>> Nobody interested? So sounds like a lazy consensus. >>> >>> Without any more comments I'll open a Jira and attach a patch >>> >>> Jacques >>> >>> >>> >>> Le 11/06/2018 à 14:02, Jacques Le Roux a écrit : >>>> >>>> Hi, >>>> >>>> I was wondering: some projects use the trunk or I guess more often a >>>> release branch as source. >>>> >>>> Should we not provide them a way to check the branch they use has the >>>> last >>>> libs versions using gradle-versions-plugin with a documented tasks, or >>>> should this stay (a bit buried) in one of our Jiras? >>>> >>>> I mean in a more global way, should we not document that for our users? >>>> >>>> Jacques >>>> >>>> >
