db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernt M. Johnsen" <Bernt.John...@Sun.COM>
Subject Re: 10.2 plans (was Re: 10.2 licensing issue)
Date Wed, 13 Sep 2006 11:05:04 GMT
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

Mime
View raw message