db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Derby regression/compatibility
Date Fri, 10 Feb 2006 04:20:14 GMT
David W. Van Couvering wrote:

>  I have also raised some concerns about what we mean by
> "compatibility" -- what interfaces must remain compatible? -- which have
> never really been resolved.

I thought this had been resolved the last time this was discussed, six
to eight months ago.

In my view all public interfaces must remain compatible.

I believe these are the public interfaces, are there any others?

- Derby's SQL language support

- Derby's JDBC support

- Derby's embedded published/public api classes
(defined by the published api javadoc target)
http://db.apache.org/derby/docs/10.1/publishedapi/

- Derby's network api - DRDA protocol support

- External behaviour defined by jar file manifest entries, e.g. OSGi
bundling now and auto-loading of JDBC driver in the future.

- Platform support
    * J2SE 1.3/1.4/1.5 support
    * J2ME/CDC/Foundation support
    * Pure Java to enable run-anywhere

Derby's versioning of its on-disk database format is described here:
http://db.apache.org/derby/papers/versionupgrade.html

There will be occasions where the Derby community does introduce
regressions or what might be considered regressions by some. Any such
item should be a deliberate choice by the community not by accident. I
think Kathey was thinking of writing up what might make a regression ok.
Examples are:

     Disabling getXXXStream to be called twice on the same column in the
same row in 10.2. Previously 10.1 and 10.1 allowed this but returned the
incorrect data. It seems a reasonable choice as it stops incorrect
behaviour and is in-line with the JDBC spec.

     Dropping support of JDK 1.3/JDBC2.1. Technically a regression but
it seems unlikely that by the time the community does this that there
will be any demand for JDK 1.3. (We've voted that it's ok to do this in
10.3, but someone has to scratch that itch)

I also assume that an api must be providing useful and reasonable
functionality for an application. For example changing a public api from
 throwing a not-implemented exception to implementing the functionality
is not a regression. :-) Applications that are relying on broken
behaviour or unreasonable un-documented behaviour should not stand in
the way of improving Derby.

If this seems like a good list I'll create a wiki page.

Dan.



Mime
View raw message