[freetds] New upcoming release, branch, rc and others...

James K. Lowden jklowden at freetds.org
Tue Jan 8 10:59:21 EST 2008


ZIGLIO, Frediano, VF-IT wrote:
> I think is time for a RC... step are usually
> 1- cvs tag -b BRANCH0_XX (should be cvs tag -b BRANCH0_82, Am I right?)
> 2- update configure.ac changing version to 0.82rc1
> 3- update userguide.sgml
> 4- package, publish and announce new version
> 
> I can manage steps 1 to 3 by myself.

Excellent.  I've been waiting to hear you say you're ready.  I didn't want
to branch a release while you were in the middle of a bunch of changes. 

Please go ahead and branch BRANCH0_82.  Yay!  

One thing I'd like to do first.  You truncated ChangeLog and moved the
2007 updates to another file.  I think our year-by-year scheme isn't that
good.  Instead, let's have a release-by-release scheme.  

	ChangeLog: 	changes in CVS HEAD since the last release
	ChangeLog-0.82: changes since 0.64
	ChangeLog-0.64: changes since 0.63
	etc. 

We don't have to go back and recreate all the old ones.  But I think it
would be good to create ChangeLog-0.82 now.  

> It's also a good time to start planning for next release!
> 
> Ideas/big TODOs:
> - support for mssql 2005 (MARS, varchar(max) and so on)
> - wide characters in ODBC
> - refactor Makefiles using GNU make
> - refactor token.c splitting token handling from upper managing
> - improve multiple request support by libTDS and upper layer
> - limit copy of data

Good ideas all, except I want to continue to support BSD make.  I don't
see any reason not to.  
 
> As you can note I have no plans for dblib/ctlib

I do, but I'm not sure when I'll get around to it.  

BLOB handling is a problem.  We make too many copies.  It doesn't matter
with normal columns, but BLOBs can exhaust virtual memory.  

bcp_moretext is the last essential bcp feature.  locale and bcp still
needs some attention, too.  

I hope the splitting out the token handling leads to a more rational API
for libtds.  I really don't like the bitwise OR flags to tell it when to
return.  

> - limit copy of data

An idea about allocation.

In db-lib -- I don't know if ODBC has a similar feature -- data can be
fetched with bound columns (dbbind) or not (dbdata).  For bound columns,
the client allocates a buffer for the data.  When libtds fetches a row, it
needs to allocate buffers only for unbound columns.  (That's not *quite*
true.  If the bound buffer is too small, libtds has to allocate enough
space for the rest of it.  dbdata should work correctly even if dbbind
allocated too small a buffer.)  

We want to make client-allocated buffers available to libtds.  That will
avoid copying kernel->libtds->client.  

Regards, 

--jkl



More information about the FreeTDS mailing list