db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: 10.2 plans (was Re: 10.2 licensing issue)
Date Tue, 12 Sep 2006 22:29:09 GMT
Andrew McIntyre wrote:

> On 9/12/06, Rick Hillegas <Richard.Hillegas@sun.com> 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.
> I'm not in favor of this option, but not because I think setting up a
> build is difficult. I think a lot of users would simply pass on the
> release if there were not precompiled binaries because they won't go
> to the trouble if it's not a completely out-of-the-box procedure. Too
> easy to just go get some other embedded database that's has binaries
> available.
>> > Option B - Release pre-compiled jars without JDBC 4.0 optional build
>> > Option A plus pre-compiled jars without JDBC 4.0, already supported by
>> > just compiling without a Java SE 6/Mustang JDK.
>> I'm afraid I don't understand option (B). How does this differ from
>> option (1)?
> With this option the binaries that are shipped do not contain the
> optional JDBC 4 compiled in, and thus are not compiled against the JDK
> 1.6 runtime classes or use the JDK 1.6 compiler and are thus
> unencumbered. i.e. just take the 'jdk16' property out of your
> ant.properties when you're building the release. The source
> distribution, because it isn't compiled, is not encumbered by either
> of these restraints either.
>> I would certainly welcome a solution which doesn't involve yanking out
>> the JDBC4 documentation!
> If we go with option B (which I think is a great idea, btw) then maybe
> just add a note for 10.2 about the need to compiling from the source
> to use the feature and a note about the legal/technical ramifications
> of using the JDBC 4 features.

Thanks, Andrew. I think I now understand that option (B) is option (1) 
with these changes:

i) No need to yank out the JDBC4 documentation

ii) Simply add a paragraph to the Release Notes explaining how to 
compile the JDBC4 bits. Also add a note explaining the legal and 
compatibility issues.

I think we would nevertheless also need the following:

iii) Various changes to the documentation to explain that, by default, 
you will get the JDBC3 implementation if you run your application on JDK 
6 but that, by compiling in the JDBC4 bits you can get an encumbered 
early access JDBC4 implementation. These changes would only have to go 
into the 10.2 branch and could be removed when we release a 
JDBC4-enabled version of Derby.

I am happy with this solution.

> Once the JDK has shipped, I personally would be ok with doing a 10.2.2
> that includes JDBC 4.0 without moving immediately to 10.3. Although,
> by the time the JDK has shipped, there may be bunch of new features
> that we may want to release, so maybe 10.3 will be the right thing to
> do at that point.

I agree that we can probably defer the discussion about release 
numbering and branch management.


> andrew

View raw message