db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: Derby regression/compatibility
Date Fri, 10 Feb 2006 04:56:36 GMT
Thanks, Dan, a Wiki page would be great.  I would suggest a table of 
interface and the level of stability guaranteed for each of them 
(basically "stable" or "stability guaranteed between minor releases 
only" or "unstable").

The issue I have with the otherwise excellent set of compatibility tests 
Raman ran was that some of the "incompatibilities" (unless I am 
mistaken) appear to be for interfaces that are not (currently) 
guaranteed to be stable, in particular the output format of ij. 
Although I think it's good to note that these differences exist by 
logging a JIRA, I don't think they should be categorized as a failure in 
regression tests.


Daniel John Debrunner wrote:
> 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.

View raw message