Re: Shared library versions

[Alexandre Oliva]

On Feb 22, 2001, Andrew Clausen <address@hidden> wrote:

> How can this be deduced from the linux version generated by libtool?

Same MAJOR number => backward-compatible changes; different MAJOR
number => backward-incompatible changes.

> If you want to go the programming language method, this
> is better (IMHO).  Of course, it's uglier, but that's because
> the algorithm is ugly.

The amount of nesting in your proposal isn't good for textual
descriptions.  I think you failed to follow it because you tried to
map it to something like what you wrote, instead of just following the
procedure one item at a time.

>> As it is now, it's simple,

> But it's not intuitive

I think it seems unintuitive for you because you're trying to
second-guess what the MAJOR and MINOR version numbers are going to
be.  Don't!  They're totally irrelevant.

> Well, I think MAJOR and MINOR, or *some* intuitive system is important.

Libtool's versioning scheme is based on CURRENT, REVISION and AGE, not
MAJOR and MINOR.  CURRENT counts the number of changes
(backward-compatible or not) in the library interface.  REVISION
counts the number of backward-compatible changes since the last
interface change.  AGE counts the number of backward-compatible
interface changes since the last backward-incompatible change.

>> Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/

> Desculpe, mas não gosto de refrigerante :P

:-)

> Serio, seu projeto parece bom... devo ler mais...

Obrigado,

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  address@hidden, redhat.com}
CS PhD student at IC-Unicamp        address@hidden, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me