> "- no caching in auto-commit mode" is probably the most important
> (this is related to memory correct?) ...

Yes, this is about memory, though it might break some applications, since
according to JDBC specs only one statement can be used with a connection in
autocommit mode at a time. Till now JayBird allows arbitrary number (until
resources are exausted) of statements to be used in parallel.

> I would rather you forge ahead and get to the next major release instead
> of spend cycles back- fitting for a patch - especially if the new release
> targeted for around May...?

Hopefully beginning of May and note, that will be only beginning of the
release cycle - first beta. I cannot tell you anything about the final
release date - Debian rule appies here - it is ready when it is ready.

> What I need is a guess (WAG) on a release so I can plan for integration
> to a client's software release - once their software is deployed it won't
> be updatable for over 6 months (environmentally isolated environment) so
> I want to get the best possible driver beforehand.
>
> So - can we expect May (or late May) for 2.0?

Not the release, that's for sure. In your case I would go with 1.5.x (if
needed we can talk about backporting) and test the application extensively
with the driver. At the end it should meet the performance requirements: if
you have to process let say 100,000 entries in peak times but application
crashes with OutOfMemoryError at 200,000 it should be acceptable for your
customer.

Sorry, that I do have no good news for you.

Roman