<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 09/27/2013 06:10 PM, Nick Boldt
      wrote:<br>
    </div>
    <blockquote cite="mid:5245ADDB.7000709@redhat.com" type="cite">
      <pre wrap="">The only thing I can currently think of is to *exclude* these features 
from the base_41 update site [3] so that only the older version from [2] 
will be included.

This is basically the process I used to build JBT 4.1.0.1 - I excluded 
everything from jbosstools-central's site/category.xml except the 
feature which had actually changed [4].</pre>
    </blockquote>
    I don't find it very easy to deal with picked dependencies on the
    producer's side. Choosing dependencies is IMO a responsibility of
    the consumer (JBT aggregator).<br>
    I tend to agree with Denis when he says that this should be
    something set in aggregator. We should ask component leads which
    version of the feature has to be aggregated (last build from branch,
    or last release?).<br>
    <br>
    However, that also shows that all versions should be bumped after a
    release, and this should be component's developer responsibility:
    when you have x.y.z released, then immediate next commit is to move
    to x.y.z+1 or x.y+1.0. Preparing versions for next stream is the
    last step of a release, not the first of the next release, so it
    should be done immediatly to prevent such issues.<br>
    If we do that, then we can filter using version ranges in our
    aggregator category.xml, which seems to be a very good trade-off
    between control and flexibility.<br>
    <br>
    <blockquote cite="mid:5245ADDB.7000709@redhat.com" type="cite">
      <pre wrap="">Looking for feedback here -- is this a good idea?
</pre>
    </blockquote>
    The idea of a per-feature filtering is good, but as explained above,
    I'm not sure that component's category.xml are the right place to
    deal with it.<br>
    <br>
    It appears that this use-case is covered by Tycho baseline
    replacement mechanism. This mechanism currently can't work for us
    until we have reproducible qualifiers (which I don't like).<br>
    FYI, I've been investigating/coding around the following Tycho bug:
    <a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=417514">https://bugs.eclipse.org/bugs/show_bug.cgi?id=417514</a> . It's an
    improvement of the baseline mechanism which wouldn't require
    reproducible qualifiers. It's not an easy one, so I can't promise
    we'll get results there, but I wish I could find something to put in
    Tycho 0.19 on this topic.<br>
    <br>
    <div class="moz-signature">-- <br>
      Mickael Istria<br>
      Eclipse developer at <a href="http://www.jboss.org/tools">JBoss,
        by Red Hat</a><br>
      <a href="http://mickaelistria.wordpress.com">My blog</a> - <a
        href="http://twitter.com/mickaelistria">My Tweets</a></div>
  </body>
</html>