David Van Couvering wrote: > A quick chime in. I am not comfortable with a source-only release of > 10.2. I think a binary release without JDBC4, plus the source for the > JDBC4 functionality for those who want it and are prepared to do a build > (e.g. option 2) seems quite reasonable to me.
Neither am I. I was thinking combined. 10.2 w/o JDBC4 compiled with JDK 1.5, 10.2 source compilable with JDK 6 for this interested in JDBC4. > > David > > Bernt M. Johnsen wrote: > >> Rick Hillegas wrote: >> >>> Hi Dan, >>> >>> Daniel John Debrunner wrote: >>> >>>> Since this is an open-*source* project, we do have other options that >>>> seem to have no legal issues to me (IANAL). >>>> >>>> Option A - Source only release with JDBC 4.0 based on proposed final >>>> draft >>>> Derby 10.2 release is source only, no pre-compiled jars, removes the >>>> dependency on the Mustang download. >>>> >>>> >>> This would seem to require that users become developers, at least to the >>> point of creating a development environment. >> >> >> Well. Derby is *not* an end-user product, so the Derby users are >> themselves developers. >> >>> I had an unhappy initial >>> experience as a Derby developer a year ago. Perhaps the situation has >>> gotten better. I recall that setting up a development environment >>> involved a lot of steps and moving parts--fetching various pieces of >>> software from various locations, editting ant configuration files, etc.. >>> I think that may discourage many users. That in turn will limit the >>> commodity testing and feedback which we hope to get from users of the >>> official release. >> >> >> I see your concerns. But I have done this maneouver several times in my >> career with various open source products (the list is very long, but I >> started with some platform problems with emacs on Sun386i in the late >> 80s), and the build process wasn't always smooth (I even once had to >> edit a files in SunOS /usr/include to make gcc compile). Don't >> underestimate the Derby users. >> >>> In addition, an uncontrolled build process would very likely complicate >>> bug reporting. For these reasons, I would recommend against this option. >> >> >> The option will always be there for the most eager users, since JDBC4 is >> always in the trunk, and even if we remove JDBC4, we can't rollback svn >> and undo what we've done. >> >> -- Bernt Marius Johnsen, Database Technology Group, Staff Engineer, Technical Lead Derby/Java DB Sun Microsystems, Trondheim, Norway
