db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew McIntyre" <mcintyr...@gmail.com>
Subject Re: pushing back release date for jdbc4-capable Derby
Date Tue, 28 Mar 2006 21:34:15 GMT
On 3/28/06, Rick Hillegas <Richard.Hillegas@sun.com> wrote:
> A while ago, I volunteered to manage a Derby release which will include
> a new feature that is important to me: an implementation of JDBC4. Based
> on the JDBC4 schedule then, I had hoped to post that release in June.
> However, because the JDBC4 schedule moved back, I must post my release
> later, most likely in October. Here is the reason:
> Under the terms of the JCP specification license, a product may not
> release for general availability if it implements JCP specification APIs
> that are not generally available. Two JCP specifications, JSRs 221 and
> 270, affect Derby. JSR 221 governs JDBC4 and JSR 270 governs Java SE 6.
> JDBC4, as part of Java SE 6, is scheduled to go GA this autumn. See
> http://www.jcp.org/en/jsr/detail?id=221&showPrint and
> http://www.jcp.org/en/jsr/detail?id=270&showPrint. So a JDBC4-capable
> Derby GA cannot post till the fall.

Disregarding any potential legalities, would we, as a community really
want to release something that isn't known to be compliant with the
final version of the spec? That would seem to run counter to the
charter of the Derby project, specifically the Standards Based part:


I assume you mentioned legalities because the ASF is a JCP member:


However, in this case I don't think we need to consider any legal issues.

> I will continue to track the evolving JDBC4 spec and still expect to
> manage a release which implements that feature. However, you must
> understand that I do not have time to manage a June release as well.
> I am sorry to bear this disappointing news.

I don't think there's a need to be disappointed. :-) These things
happen. Personally, I think it makes sense from several perspectives
to have a release around JDBC 4 that implements the final version of
the spec, not an early draft. Does anyone disagree?

That said, October is a long way away. That would be almost a year
between the 10.1.2 release and 10.2. So, I think it would be a good
idea to have another 10.1 maintenance release in the meantime. There
have been numerous XA fixes which have gone into the 10.1 branch
recently, and perhaps we can have another "bug drive" like Kathey held
for 10.1.2 to drum up some interest in fixing some of the numerous
open code bugs and porting some of the smaller fixes from 10.2 to 10.1
(like the recent fix for retrieving Float values, e.g.).

And since I suggested it, yes, I'll volunteer to head up the 10.1.3 release. :-)


View raw message