FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

Further discusions reached these tentative points of agreement:

1.  For 0.61, dblib will have a major version number of 3, bumped up from
0.60.
  
2.  Henceforward, the criteria for bumping the .so will be constrained to
the public API, as defined by the vendors and doc/api_status.txt.  If
someone chooses to use something in our .h files that lies outside the
vendor-provided specification, he's on his own.  Well behaved client
programs, on the other hand, can trust the .so version number.  

3. The libtds API will continue to change.  Those changes will affect the
libtds .so number, but not that of the public client libraries.  See prior
point, #2.  

4. Changes to enumerated types (and #define types) count as changes to the
API, for obvious technical reasons.  

5. We'll add a notice to this effect somewhere in our documentation, so no
one can say they didn't know.  :-)

By following this policy, the vast majority of programs will not require
recompilation for most releases, especially if we are conservative with our
enumerated type values.  After all, we're mostly filling in the outline
provide by the vendors, so there's not much call to remove functions from
the public API.  

Comments welcome, naturally.  That's why I'm writing.  

--jkl


> -----Original Message-----
> From: Steve Langasek [mailto:vorlon AT netexpress.net]
> Sent: February 5, 2003 8:24 PM
> To: freetds AT lists.ibiblio.org
> Subject: Re: [freetds] so version bump for dblib?
> 
> 
> On Wed, Feb 05, 2003 at 12:08:43PM -0500, Castellano, Nicholas wrote:
> > The following entry points were removed between BRANCH0_60 
> and HEAD of
> > libsybdb.  By a strict interpretation of rule 6 in the libtool info
> > documentation, AGE should be set to 0, and we get a major 
> version bump as a
> > result.
> 
> Ok.  I think this can go either way; most of the functions 
> you list are
> not made available in the sybdb headers, and any that are were clearly
> never intended to be public entry points.  If someone thinks there's a
> danger someone may be using some of these functions from 
> libsybdb, I have
> no objection to bumping the soname -- but I also don't think this is
> enough of an issue that I'm going to do it myself.
> 
> > Since we pull in all of libtds, the following removed 
> libtds entry points
> > were also removed from libsybdb:
> > tds7_send_login
> > tds_add_input_param
> > tds_alloc_config
> > tds_free_column
> > tds_free_config
> > tds_get_config
> > tds_get_ntstring
> > tds_is_control
> > tds_is_doneinproc
> > tds_is_end_of_results
> > tds_is_error
> > tds_is_fixed_token
> > tds_is_message
> > tds_is_result_row
> > tds_is_result_set
> > tds_msg_get_proc_name
> > tds_msleep
> > tds_process_column_row
> > tds_process_env_chg
> > tds_reset_msg_info
> > tds_send_login
> > tds_strtok_r
> > tds_write_packet
> 
> Is there any reason for not dynamically linking dblib (et al.) against
> libtds, so tds-related ABI bumps can be unequivocally 
> avoided?  I thought
> I'd seen motion in this direction at various points in the 
> past, but my
> latest build shows libsybdb.so is statically linked against libtds.
> 
> -- 
> Steve Langasek
> postmodern programmer
> 


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above.  If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.