<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 01/19/2012 01:36 AM, Wichmann, Mats D wrote:
    <blockquote
cite="mid:CADJYUdhxVPbVd_3N9O6VH+uLVS3rAnF1kN4peL9TZtBcfo-h7A@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div bgcolor="#FFFFFF" text="#000000">It's not easy to teach
            Navigator to show such data, but I can generate some
            approximations by myself :)<br>
            <br>
            Here is comparison of versions of components interesting in
            the context of LSB (5 tables - sles10, rhel4/5 and
            debian5/6):<br>
            <a moz-do-not-send="true"
              href="http://dsilakov.ru/distr_comps.html" target="_blank">http://dsilakov.ru/distr_comps.html</a><br>
            <br>
            Hopefully highlighting is almost self-explaining - green is
            good, red is not:) The only really significant change (that
            did affect LSB development) is Qt update in SLES 10 SP2. It
            is likely that we want to store this info in the db.</div>
        </blockquote>
        <div><br>
        </div>
        <div><br>
        </div>
        <div>This is neat info. &nbsp;The first-last of a series seems sane,
          and except for the case you cite of SLES, the changes have
          been ones we don't need to keep. If we do a one-time trim now,
          I guess the question becomes one of moving forward: if we have
          a release series like RHEL which now uses major.minor, and we
          prune so we store X.0 and X.Y, then X.Y+1 comes out... do we
          immediately prune out X.Y after importing X.Y+1? &nbsp;Or do we
          then hit the case where somebody is still working on porting
          to X.Y and they get irritated that specific information
          vanished?</div>
      </div>
    </blockquote>
    Good question. Maybe for the current major branch we could keep all
    minor updates and drop intermediate ones only when the major update
    occurs?<br>
    <br>
    In case of micro updates it doesn't seem to make much sense to store
    intermediate versions. E.g., Debian 6.0.x -&gt; 6.0.(x+1) is really
    a 'micro' update not only because it only changes micro version, but
    because there are almost no changes in versions of components, not
    speaking about libraries/binary symbols.<br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Regards,
Denis.</pre>
  </body>
</html>