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: 10.2 plans (was Re: 10.2 licensing issue)
Date Tue, 12 Sep 2006 22:16:36 GMT
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.


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.

View raw message