n abuse that only fosters
misunderstanding of the purpose of library versions.  Instead, use the
'-release' flag (*note Release numbers::), but be warned that every
release of your package will not be binary compatible with any other
release.

   The following explanation may help to understand the above rules a
bit better: consider that there are three possible kinds of reactions
from users of your library to changes in a shared library:

  1. Programs using the previous version may use the new version as
     drop-in replacement, and programs using the new version can also
     work with the previous one.  In other words, no recompiling nor
     relinking is needed.  In this case, bump REVISION only, don't touch
     CURRENT nor AGE.

  2. Programs using the previous version may use the new version as
     drop-in replacement, but programs using the new version may use
     APIs not present in the previous one.  In other words, a program
     linking against the new version may fail with "unresolved symbols"
     if linking against the old version at runtime: set REVISION to 0,
     bump CURRENT and AGE.

  3. Programs may need to be changed, recompiled, and relinked in order
     to use the new version.  Bump CURRENT, set REVISION and AGE to 0.

In the above description, _programs_ using the library in question may
also be replaced by other libraries using it.