Andrew McIntyre wrote:
On 9/12/06, Rick Hillegas <[EMAIL PROTECTED]> 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.
Regards,
-Rick
andrew
