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.
