bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Shared library versions


From: Andrew Clausen
Subject: Re: Shared library versions
Date: Thu, 22 Feb 2001 13:33:50 -0300

Alexandre Oliva wrote:
> 
> On Feb 21, 2001, Andrew Clausen <address@hidden> wrote:
> 
> > That is SURREAL.  I can't wait to see what 3:0:4 will look like...
> 
> 3:0:4 is pure non-sense.  From the libtool manual:

Exactly.  So it should have assertions...

> If you follow the procedure you quoted, step by step, you won't ever
> get such a version number.

Agreed.
 
> Don't attempt to guess what the resulting MAJOR and MINOR version
> numbers are going to be.  They are not relevant.

I disagree.  Users should be able to deduce:
* which version is newer
* given two versions, whether there was a compatible or incompatible
change to the API

from the version number.

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

> Let me try to rephrase it.
> 
> before_release () {
>   if (library_has_changed())
>     r++;
> 
>   if (interfaces_have_changed())
>     c++, r=0;
> 
>   if (interfaces_have_been_added())
>     a++;
> 
>   if (interfaces_have_been_removed())
>     a=0;
> }

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.

        if (library_has_changed) {
                if (!interfaces_changed) {
                        r++;
                } else {
                        c++;
                        r = 0;
                        if (intefaces_removed)
                                a++;
                        else if (interfaces_added)
                                a = 0;
                }
        }

This translates to:
* if there were no interface changes, only increment REVISION
* if there were intefaces changes, increment CURRENT, and set REVISION
to zero
* if interface(s) were removed, increment AGE
* if interface(s) were added (and none removed), set AGE to zero.

> > start: (rule 1)
> >       libtool=0:0:0,  linux=0.0.0
> 
> > add an interface: (rule 4, 5)
> >       libtool=1:0:1,  linux=0.1.0
> 
> No problem here, right?  0.1 is exactly what you expected for a
> release after 0.0 in which you have only added interfaces.

Yes, all good here :-)

> > remove an interface: (rule 4, 6)
> >       libtool=2:0:0,  linux=2.0.0
> 
> I suppose you'd expect to get the major version number 1 here, right?

Yes.

> I think it would be possible to modify libtool's procedures so as to
> get what you want.  For example, we could change step 6 so as to
> subtract from CURRENT the value of AGE before step 5, before zeroing
> AGE.

Yes, ugly

> But I think there would be corner cases that would force the
> introduction of additional clauses in the procedure.

I think this is a bad thing, agreed.

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

But it's not intuitive, for either the libtool version or the
linux version.  (And I don't think it's simple either)

> and it always works, even though it will skip some major
> version numbers.  But, as I wrote before, this doesn't matter.  All
> that matters is to have the same MAJOR revision number when binary
> compatibility is retained, and different MAJOR revision numbers when
> it is not.  You shouldn't think of the MAJOR and MINOR version
> numbers; think of CURRENT, REVISION and AGE and everything will be
> fine.

Well, I think MAJOR and MINOR, or *some* intuitive system is important.
People will screw up the versioning for eternity, unless it is somewhat
sane. 

Andrew Clausen

> 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...



reply via email to

[Prev in Thread] Current Thread [Next in Thread]