<html>
    <head>
      <base href="http://bugzilla.slf4j.org/" />
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Priority</th>
          <td>P5
          </td>
        </tr>

        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW --- - binary compatibility broken from 1.6.4 to 1.6.6"
   href="http://bugzilla.slf4j.org/show_bug.cgi?id=313">313</a>
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>slf4j-dev@qos.ch
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>binary compatibility broken from 1.6.4 to 1.6.6
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>enhancement
          </td>
        </tr>

        <tr>
          <th>Classification</th>
          <td>Unclassified
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>Linux
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>tycho.lamerigts@imc.nl
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>PC
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>1.6.x
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>Core API
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>SLF4J
          </td>
        </tr></table>
      <p>
        <div>
        <pre>Several LoggerFactory static fields with INITIALIZATION in the name had their
spelling corrected in slf4j-api version 1.6.6. Because the fields are not
private but have default access, this constitutes a breach of binary
compatibility (see Java Language Specification, section 13.4.8). In theory,
somebody could have written code in the org.slf4j package that relies on these
fields.

It would be good if this binary incompatibility could be documented in the FAQ,
which now incorrectly states that binary compatibility to date has never been
broken.

There are still many libraries out there that use 1.6.x versions. I have a
build system that automatically checks for binary compatibility conflicts. It
reported this one and I wasted some time finding the root cause and
white-listing this conflict. It would have saved me time if this had been
documented in the FAQ.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>