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.
