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.
David
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.
