Skip to Content.
Sympa Menu

freetds - Re: [freetds] Jeopardy answer: What is 1.0?

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Robert Klemme <shortcutter AT googlemail.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Jeopardy answer: What is 1.0?
  • Date: Wed, 7 Dec 2005 17:46:12 +0100

2005/12/6, Lowden, James K <LowdenJK AT bernstein.com>:
> > From: Robert Klemme
> > Sent: Tuesday, December 06, 2005 12:08 PM
> >
> > How true. That reminds me that I always wanted to ask about freetds
> > version number policy. When can we expect to see 1.0 (or even
> > higher)? On one hand I have the feeling that 0.63 is pretty much
> > stable (at least the bulk loader which is the only one we extensively
> > tested so far) on the other hand 0.63 seems to indicate quite a
> > gap to 1.0 which irritates me a bit...
>
> Well, we haven't defined what 1.0 would be. It's been awhile since I
> thought about it, too.

:-)

> I suggested a few years ago -- about when api_status.txt first appeared
> -- that we could measure our progress as a percentage of completed
> functions. That's a little simplistic because:
>
> 1. Some functions are very complex, particularly in ODBC and ct-lib.
>
> 2. Some functions will never be implemented.
>
> Examples: db-lib has "browse" functions that are museum pieces today.
> There are svr functions that exploit server-side operations that no one
> much uses. Some of the placeholder functionality requires parsing the
> SQL to work with Microsoft servers.
>
> There are other things. bcp works well when it works, but when there
> are problems with the data, it can take a TDSDUMP log to diagnose them.
> Similarly, when the libraries are used correctly, they work, but when
> the programmer makes mistakes, the library frequently passes the mistake
> to a lower level, which fails in mysterious ways. We almost need an
> "antitest" module to drive that side.
>
> Finally, documentation. IMHO there should be a complete, accurate
> reference manual documenting our implementation. Bugs are behavior in
> exception to that documented. No document means all behavior is
> undefined, bugwise. We can't say we have N bugs absent documentation.
>
> Do I think this is achievable? No. There are 100 guys willing to work
> on Firefox extensions for every one interested in "finishing" FreeTDS.
> Does that mean, then, that my standards are too high. Not as I see it,
> but maybe. Convince me.

I completely agree with your general approach. Unfortunately I cannot
comment on the details of feature coverage as I haven't seen much of
freetds yet and don't know your complete list. Having said that both
from a marketing perspective and for developer satisfaction it's
probably better to not be so ambitious. To feel comfortable you could
start defining a road map that contains assignments of features to
major version numbers. 1.0 doesn't need to have all whistles and
bells but if it's reasonable complete and stable and has at least a
basic set of documentation that might be enough (freetds is probably
past that already). You can go from there to 2.0 in whatever (small)
steps you see fit. Also, you don't need to fix dates which makes up
for certain flexibility. :-)

I'd be glad to offer support but we're understaffed for over a year
now (don't find an appropriate candidate) so I don't thing we have
resources available. We don't even have for our own development. :-(

Kind regards

robert




Archive powered by MHonArc 2.6.24.

Top of Page