<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

  </head>

  <body>

    <br>

    <blockquote type="cite"

      cite="mid:c1531b19-aa1b-682f-a7ad-528e870abc27@mccallumwhyman.com">

      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

      <div dir="auto"><i>Reposted with correct branch identifier</i>.<br>

      </div>

      <div dir="auto"><br>

      </div>

      <div dir="auto">I thought that a fixes branch was only for bug

        fixes and not for issuing non-backwards compatible changes.

        However, TFieldType in db.pas now has 6 extra elements.</div>

      <div dir="auto"><br>

      </div>

      <div dir="auto">The result is that IBX no longer compiles with the

        fixes_3_2 branch. I have also heard the same for zeoslib.</div>

    </blockquote>

    <br>

    As far as I can see ZEOS is full of checks like:<br>

    {$IF FPC_FULLVERSION>=30100} ...<br>

    <br>

    So I think that one more check:<br>

    {$IF FPC_FULLVERSION>30200} <br>

                  {$DEFINE WITH_FTSHORTINT}                 //

    ftShortInt is supported<br>

                  {$DEFINE WITH_FTBYTE}                     // ftByte is

    supported<br>

                  {$DEFINE WITH_FTEXTENDED}                 //

    ftExtended is supported<br>

                  {$DEFINE WITH_FTLONGWORD}                 //

    ftLongWord is<br>

    {$ENDIF}<br>

    ... is not so big problem? (I see there is already in ZEOS such

    check added ...)<br>

    <br>

    In IBX there you have "DefaultFieldClasses" array which is affected,

    right?<br>

    <br>

    I agree that it is not ideal situation, but release cycle for major

    versions of FPC are so long that postpone all these additions to

    major releases means that users must wait years ...<br>

    <br>

    L.<br>

  </body>

</html>