FreeTDS Development Group

[Steve Langasek <vorlon AT netexpress.net>]

On Tue, Sep 17, 2002 at 12:58:57AM -0400, James K. Lowden wrote:

> Got it, read it, thanks for the pointer.  Read it before, without thinking
> I'd be responsible; the difference between trying to understand a language
> and trying to speak it.  Even now, actually, it's not obvious to me anyway
> that the version had to be changed, since nothing disappeared from the
> source code interface.

The issue is that the soname is used at runtime by the linker to identify
libraries; that is, it's part of the *binary* interface.  So if symbols
disappear from the library, it's important that programs not break when
the library is upgraded, and changing the soname is the way to do this.

> Understood.  To make the future a better place, I would like to suggest we
> make a joint effort to keep the libtool version system in mind as we
> affect the public interface.  If he who modifies the interface (including
> adding a function) updates its Makefile.am in accordance with the libtool
> system, everyone will benefit.  

> For instance, AIUI, the ODBC lib is 0.0.0.  I don't know; I never build
> it, but let's say so for argument's sake.  The rules are:

It is at 0, for the record.  However, I would actually argue that ODBC is
a special case, since the ABI for ODBC drivers is fixed in place by
Microsoft, and any changes to tdsodbc's interface should be bugfixes
only.  Indeed, at least for Debian, I don't ship this as a shared library
at all, just as a plugin that can be used with driver managers -- so
library versioning is a total non-issue, AFAICT.

>   3. If the library source code has changed at all since the last
>      update, then increment REVISION (`C:R:A' becomes `C:r+1:A').

> Yes: 0.1.0

>   4. If any interfaces have been added, removed, or changed since the
>      last update, increment CURRENT, and set REVISION to 0.

> Yes: 1.0.0

>   5. If any interfaces have been added since the last public release,
>      then increment AGE.

> Yes: 1.0.1?  Or is that an "else" condition?  

If both 4 and 5 apply, you would increment both, according to the libtool
rules.  Although, I rarely pay much attention to anything after the
library major number ('CURRENT'), since it's the only part that's encoded
into the library soname.

>   6. If any interfaces have been removed since the last public release,
>      then set AGE to 0.

> No: Leaving me with 1.0.0 (best guess) or 1.0.1 (interpreting the rule
> literally).  

1.0.0 or 1.1.0, depending on the result of rule 3, I believe.


> > Is there any chance that 0.61 can be branched from 0.60 and released in
> > short order to address this library incompatibility?  I can't upload a
> > FreeTDS package to Debian that breaks existing apps in this way, so I'll
> > either need to bump the soversion on 0.60 myself, or wait until 0.61
> > comes to term before I can get updated libs into Debian unstable.

> I will try to move quickly to offer you 0.60.1, along these lines:

> 1. checkout R0_60, plus head Makefile.am's.  The Makefiles have not
> changed materially since the release.  
> 2. apply the fixes you recommend.  
> 3. tag as R0_601
> 4. cvs commit; make dist; make Steve happy ;)  
> 5. update ibilio & readme.  

> Howzat?

That would do it... :)  Would it help if I went ahead and did the branch
for you from R0_60 and directly applied the (minimal) changes to CVS?

Steve Langasek
postmodern programmer

Attachment: pgp_TnuM9rT6x.pgp
Description: PGP signature