<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    In similar vain dependabot tries to aggressively upgrade without
    understanding a proper versioning scheme. It only understands major,
    minor &amp; patch level.<br>
    <br>
    My initial encounter didn't show good results: <a
      href="https://github.com/wolfc/jboss-eap7/pulls">https://github.com/wolfc/jboss-eap7/pulls</a><br>
    At that point you're stuck into a mode of "teaching" dependabot what
    you really want without any form of control.<br>
    <br>
    Being able to do authoritative configuration upfront is a must to
    retain sanity. <span class="moz-smiley-s1"><span>:-)</span></span><br>
    <br>
    Carlo<br>
    <br>
    <div class="moz-cite-prefix">On 02-09-19 11:58, Ladislav Thon wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:07f6be88-d157-2212-9072-35e80d1ca0ed@redhat.com">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <p>I took a quick look at the README of Tomas's project and the
        main difference seems to be the opt-in approach, as opposed to
        Dependabot's opt-out approach. Dependabot attempts to update
        everything, and you have to opt out of certain dependencies (by
        commenting in pull requests!). If you have multiple repositories
        with similar needs, you have to opt out for each repository
        again and again. If I understand Tomas's project correctly, you
        can define configuration upfront, and it won't touch
        dependencies that are not configured.</p>
      <p>Tomas, please correct me if I'm wrong here :-)<br>
      </p>
      <p>LT<br>
      </p>
      <div class="moz-cite-prefix">On 02. 09. 19 11:45, Rostislav
        Svoboda wrote:<br>
      </div>
      <blockquote type="cite"
        cite="mid:71F29986-5E06-42D5-8F47-8A04BD90A0F4@redhat.com">
        <meta http-equiv="Content-Type" content="text/html;
          charset=windows-1252">
        This tools sounds similar to <a
          href="https://github.com/marketplace/dependabot-preview"
          class="" moz-do-not-send="true">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 &lt;<a
                  href="mailto:thofman@redhat.com" class=""
                  moz-do-not-send="true">thofman@redhat.com</a>&gt;
                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="" moz-do-not-send="true">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="" moz-do-not-send="true">https://github.com/jboss-set/dependency-alignment-configs/blob/master/wildfly-18-minimal.json#L44</a><br
                    class="">
                  [3] <a class="moz-txt-link-freetext"
                    href="https://github.com/TomasHofman/wildfly/pulls"
                    moz-do-not-send="true">https://github.com/TomasHofman/wildfly/pulls</a><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="">
                  <a class="moz-txt-link-abbreviated"
                    href="mailto:wildfly-dev@lists.jboss.org"
                    moz-do-not-send="true">wildfly-dev@lists.jboss.org</a><br
                    class="">
                  <a class="moz-txt-link-freetext"
                    href="https://lists.jboss.org/mailman/listinfo/wildfly-dev"
                    moz-do-not-send="true">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br
                    class="">
                </div>
              </div>
            </blockquote>
          </div>
          <br class="">
        </div>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <pre class="moz-quote-pre" wrap="">_______________________________________________
wildfly-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:wildfly-dev@lists.jboss.org" moz-do-not-send="true">wildfly-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" moz-do-not-send="true">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></pre>
      </blockquote>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
wildfly-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/wildfly-dev">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></pre>
    </blockquote>
    <br>
  </body>
</html>