I think monthly would be a good interval. I think the Norway team has
the machinery to generate full sets of jars, including documentation, on
demand. From a previous thread, I got the impression that turning one of
these productions into a "snapshot" involves bolting on some interim
Release Notes, explaining the delta from the previous snapshot. Does
that sound adequate or do you think a snapshot is fancier?
Seems to me we have to balance some factors:
1) The cost of generating a snapshot. For me that cost is largely a
matter of compiling the delta notes. Other people may incur other expenses.
2) The value of getting early feedback.
3) The cost of premature feedback on half-baked code.
Regards,
-Rick
Daniel John Debrunner wrote:
Rick Hillegas wrote:
I need to push back the freeze date for the JDBC4 work. The following
issues have created more work than I originally estimated:
1) Upgrade issues raised by Kathey, tracked in DERBY-1107
2) Missing method signatures, tracked by DERBY-1146
3) The continued evolution of the JDBC4 spec itself
4) Some work on forwarding PooledConnection methods, which needs
analysis and description in JIRA
I do not have a new freeze date yet, but I expect it will fall in May,
still comfortably far away from an autumn release date for 10.2. I will
let the community know when I have a new freeze date.
At this time, I'd like to ask other 10.2 contributors if the original
freeze date of April 7 still looks reasonable. If not, please let us
know. If you need to slip your freeze date and you can estimate a better
date, please let us know that too.
Slipping the JDBC4 freeze date will affect the completeness of the alpha
snapshot we want to post in May. As Ole noted,
http://www.multinet.no/~solberg/public/Apache/DerbyJDK16/builds/ holds
current snapshots of the raw JDBC4-capable Derby.
Errrmmm, what freeze date? No release means no freeze date until a new
release starts up. A snapshot can go up at any time, we should probably
put them up fairly frequently, monthly?
Dan.
