freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
Re: [freetds] New upcoming release, branch, rc and others...
- From: "James K. Lowden" <jklowden AT freetds.org>
- To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
- Subject: Re: [freetds] New upcoming release, branch, rc and others...
- Date: Tue, 8 Jan 2008 10:59:21 -0500
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
-
[freetds] New upcoming release, branch, rc and others...,
ZIGLIO, Frediano, VF-IT, 01/08/2008
-
Re: [freetds] New upcoming release, branch, rc and others...,
Sebastien FLAESCH, 01/08/2008
- Re: [freetds] New upcoming release, branch, rc and others..., ZIGLIO, Frediano, VF-IT, 01/08/2008
- Re: [freetds] New upcoming release, branch, rc and others..., James K. Lowden, 01/08/2008
-
Re: [freetds] New upcoming release, branch, rc and others...,
James K. Lowden, 01/08/2008
-
Re: [freetds] New upcoming release, branch, rc and others...,
ZIGLIO, Frediano, VF-IT, 01/08/2008
-
Re: [freetds] New upcoming release, branch, rc and others...,
James K. Lowden, 01/08/2008
-
Re: [freetds] New upcoming release, branch, rc and others...,
ZIGLIO, Frediano, VF-IT, 01/09/2008
- Re: [freetds] New upcoming release, branch, rc and others..., James K. Lowden, 01/09/2008
-
Re: [freetds] New upcoming release, branch, rc and others...,
ZIGLIO, Frediano, VF-IT, 01/09/2008
-
Re: [freetds] New upcoming release, branch, rc and others...,
James K. Lowden, 01/08/2008
-
Re: [freetds] New upcoming release, branch, rc and others...,
ZIGLIO, Frediano, VF-IT, 01/08/2008
-
Re: [freetds] New upcoming release, branch, rc and others...,
Sebastien FLAESCH, 01/08/2008
Archive powered by MHonArc 2.6.24.