db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew McIntyre" <mcintyr...@gmail.com>
Subject Re: 10.2 plans (was Re: 10.2 licensing issue)
Date Tue, 12 Sep 2006 21:47:21 GMT
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.

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.

andrew

Mime
View raw message