FreeTDS Development Group

["James K. Lowden" <jklowden AT schemamania.org>]

On Tue, 17 Sep 2002 15:14:14 -0500, Steve Langasek <vorlon AT netexpress.net>
wrote:

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

Steve, I'm working on this right now.  It's late, so I'm going to check in
what I've got.  

I wonder about your logic, old man.  We don't implement the whole ODBC ABI
by a long shot.  When we add interfaces -- albeit interfaces that "should"
be there (for some value of should) -- doesn't libtool say we should up
the version number?  Isn't half the game offering information to people
and programs about what's different, irrespective of whether what came
before was more-or-less in conformance?  

Let me try that in English.  Aren't version numbers there to tell us that
something has changed?  

If we say "the ABI ... is fixed in place by Microsoft", OK, but how is
that different at the end of the day from the case of db-lib?  Seems to me
the spec is immaterial to the version number question.  

Deferring to you, I didn't touch odbc/Makefile.am.  Left to my own
devices, I would have selected 1.0.0.  (Up +1 from 0).  

+++

I added version information for ct-lib (0 1 0) and libtds (1 0 0) based on
a diff of the nm output.  libtds is *very* different; behavior of ct-lib
is consequently different.  

I didn't tag everything.  Hope that doesn't disappoint.  Thought we should
hash this out first.  

Regards, 

--jkl