db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: Planning for a 10.1 release
Date Wed, 25 May 2005 02:18:03 GMT
Andrew McIntyre wrote:
> 
> I'm thinking that in the interests of getting an official release out
> with the Derby client, I'd like to aim for a release in about two
> weeks or so.
> 

When we're ready - not before :-)

> 
> - Jeremy, in what timeframe do you think you will have a working
> prototype for the Datasource API changes? If you need help running
> tests against the prototype, please email me, I can help out with
> that. But, it's not clear to me that this is something that must be in
> the 10.1 release. Is this something that could be deferred to a 10.2
> (or even a 10.1.x) release? It's not unusual to manage API changes at
> release boundaries, so I don't think that having to support the
> current Datasource API going into the future is necessarily a reason
> to hold up this release.
> 

There is a "working" prototype in the datasource branch - by some 
definition of "working" anyway :-) It can connect to the server both 
client and embedded and supports several of the Derby specific properties.

Implementation is here:
http://svn.apache.org/viewcvs.cgi/incubator/derby/code/branches/datasource/src/java/org/apache/derby/api/BasicDataSource.java?view=markup
http://svn.apache.org/viewcvs.cgi/incubator/derby/code/branches/datasource/src/java/org/apache/derby/api/DerbyDataSource.java?view=markup

There are unit tests as part of this module that test the connect 
behavior. It uses the existing implementations underneath so I would 
anticipate major problems. I could use help branching the client test 
framework so that it uses this instead.


Part of this issue is the alignment of behaviour of the client and 
embedded drivers (e.g. trace) - the vote was in favour of doing this and 
this prototype is one option for doing that; I have not seen any other 
changes so far. It would be good to make a decision on whether we are 
going to unify the drivers before I add more to the prototype or someone 
else starts changing the existing implementations.

I still think introducing a major new API in this release with the 
potential of it then changing incompatibly in the next one (especially a 
dot release) is confusing.

--
Jeremy

Mime
View raw message