db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Derby regression/compatibility
Date Fri, 10 Feb 2006 17:19:00 GMT
I agree that these tests should not be logged as regression test
failures (until the compatibility suite is part of the nightly
regression test).  That is not saying they are not important, it
is just not what the regression test component is trying to track.

David W. Van Couvering wrote:
> 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.
> 
> David
> 
> 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.
>>
>>


Mime
View raw message