<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">This tools sounds similar to <a href="https://github.com/marketplace/dependabot-preview" class="">https://github.com/marketplace/dependabot-preview</a> <div class="">What are the main differences ?</div><div class=""><br class=""></div><div class="">Rostislav<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 2 Sep 2019, at 09:44, Tomas Hofman <<a href="mailto:thofman@redhat.com" class="">thofman@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hello,<br class=""><br class="">would the Wildfly team be interested in (or opposed to) receiving component <br class="">upgrade PRs, which would be created automatically when a new component version <br class="">is released? (I'm talking about new micro/SP versions, depending on the <br class="">component, i.e. version that could be reasonably expected to be suitable for <br class="">consumption, without issues like breaking API changes etc.)<br class=""><br class="">I'm working on a tool [1], which is able to provide these PRs.<br class=""><br class="">The tool scans given project for dependencies, and then looks at what versions <br class="">of those dependencies are available in Maven Central and possibly other <br class="">repositories. I can configure rules for each dependency, that specify what <br class="">versions should be considered viable for upgrading (e.g. for "org.picketlink:*" <br class="">we would only offer new "SP" builds in the same micro, for most of the other <br class="">dependencies we would only offer new micros, and some artifacts would perhaps <br class="">be blacklisted). Example of this configuration is here [2].<br class=""><br class="">Advantages that I believe could be gained from this:<br class=""><br class="">* It would bring us an advantage of having new component micros tested soon in <br class="">Wildfly, and therefore having more confidence when we need to do the same <br class="">upgrades in EAP.<br class=""><br class="">* It would also help in preventing EAP running ahead of Wildfly in component <br class="">versions, which happens occasionally. EAP release coordinator usually spots <br class="">this problem and creates missing PR in Wildfly, but it's a manual check and <br class="">therefore a small risk remains.<br class=""><br class="">* It would ensure Wildfly is consuming latest component fixes.<br class=""><br class="">You can review PRs generated last week in my fork of Wildfly [3].<br class=""><br class="">It's a work in progress, I expect the tool and it's configuration would evolve <br class="">according to experiences we would get from using it...<br class=""><br class="">What do you think?<br class=""><br class="">[1] <a href="https://github.com/TomasHofman/maven-dependency-updater/" class="">https://github.com/TomasHofman/maven-dependency-updater/</a><br class="">[2] <br class=""><a href="https://github.com/jboss-set/dependency-alignment-configs/blob/master/wildfly-18-minimal.json#L44" class="">https://github.com/jboss-set/dependency-alignment-configs/blob/master/wildfly-18-minimal.json#L44</a><br class="">[3] https://github.com/TomasHofman/wildfly/pulls<br class=""><br class="">-- <br class="">Tomas Hofman<br class="">Software Engineer, JBoss SET<br class="">Red Hat<br class="">_______________________________________________<br class="">wildfly-dev mailing list<br class="">wildfly-dev@lists.jboss.org<br class="">https://lists.jboss.org/mailman/listinfo/wildfly-dev<br class=""></div></div></blockquote></div><br class=""></div></body></html>