______   ___    ___
    /\  _  \ /\_ \  /\_ \
    \ \ \L\ \\//\ \ \//\ \      __     __   _ __   ___ 
     \ \  __ \ \ \ \  \ \ \   /'__`\ /'_ `\/\`'__\/ __`\
      \ \ \/\ \ \_\ \_ \_\ \_/\  __//\ \L\ \ \ \//\ \L\ \
       \ \_\ \_\/\____\/\____\ \____\ \____ \ \_\\ \____/
        \/_/\/_/\/____/\/____/\/____/\/___L\ \/_/ \/___/
                                       /\____/
                                       \_/__/


                API compatibility information.

         See readme.txt for a more general overview.


Introduction

Once Allegro 4.0 is released, we plan to maintain backward compatibility at the Application Programming Interface level for the subsequent stable releases of the 4.x series, that is for the releases with an even minor version number. For example, that means you will be able to compile your program written for version 4.0.0 with version 4.0.23 or version 4.2.1 of the library. However, in order to fix some minor inconsistencies of the original 4.0 API, we may make exceptions to the rule and break strict backward compatibility in a few cases. But this is guaranteed to never happen in a stable series for which major and minor version numbers are fixed; in other words, two stable versions that differ from each other only by the revision (3rd) number will be strictly backward compatible.


Changes between 4.2.x and 4.4.x series


Changes between 4.0.x and 4.2.x series

Deprecated materials

The following items have been deprecated and the main documentation was purged of any references to them. If you are still using any of those, now might be a good time to get rid of them (within parentheses is the symbol most likely to be a replacement for the obsolete one, if any). However they are still supported for the sake of backwards compatibility, unless you define the symbol ALLEGRO_NO_COMPATIBILITY prior to including Allegro headers.