db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: Proposal for 10.2 release schedule
Date Thu, 22 Jun 2006 23:29:34 GMT
Jean and Dan, you raise good points

(a) what happens if someone downloads this "GA-ready but not GA" release 
of Derby.  If for some reason we have to do a respin of the release (see 
(b)), how will they later know that it's not actually an official 
release of Apache?

(b) is there a possibility, however, slight, that the JDBC spec could 
change after we have marked a release "GA-ready"

I think these are great points for discussion.

I get the sense that we all want to make this work, but are not sure how 
just yet.

I have a suggestion, and I'm sure I'm missing something, but here goes. 
  Is there a way we can vote on the release, and if it passes, Rick can 
flip the GA bit, sign it and put it on the shelf, but not make it 
available for download, even from the Derby site?  This would allow us 
to re-spin if necessary (although I don't think it's likely) due to a 
last-minute change to JDBC, and would prevent a user from ending up with 
a release that looks and smells like it's an official Apache release but 
actually isn't.


Daniel John Debrunner wrote:
> Jean T. Anderson wrote:
>> David Van Couvering wrote:
>> ...
>>> In order for this to work, we need Java DB to be based on an official,
>>> "GA-ready" release of Derby to be what Sun redistributes in Mustang.
>>> Otherwise databases created in Mustang will be "locked in" to Java DB.
>>> The problem is that it can't *actually* be GA until after JCP approves
>>> JSR 221, JDBC 4.0, which will happen in tandem with the GA release of
>>> the JDK, around 5 weeks after the JDK team needs their final integration
>>> bits from all the pieces going into it.
>> in other words, we have a classic catch-22. :-)
> Are there any dates around JDBC 4.0/JSR221 that need to be factored in?
> I'm curious as to how we can vote on the release that's supporting JDBC
> 4.0 if the spec isn't final and/or generally available for people to
> read. Maybe we would be just voting on the current functionality of
> *Derby* and if it happens to match JDBC 4.0 that's a bonus.
> Dan.

View raw message