db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: Derby regression/compatibility
Date Fri, 10 Feb 2006 04:55:32 GMT
Daniel John Debrunner wrote:

>In my view all public interfaces must remain compatible.
>I believe these are the public interfaces, are there any others?
[snip public api list]

>- External behaviour defined by jar file manifest entries, e.g. OSGi
>bundling now and auto-loading of JDBC driver in the future.
Would sticky issues like ability to mix jar versions,   maintaining
existing jar file names,  conforming to exisiting documented security
permissions for  existing behaviour and ensuring jar file growth is
commesurate with functionality improvement fall into this category?

Also, there are gray areas
- Changes to things like error codes, sqlstates and system tables. 
- Changes to make client match embedded for implementation defined

I think here common sense and  sensitivity to users  has  to guide us as
to when a change is acceptable or a lot of advance notification to the
user community is needed.    Changing  SQLStates from null to something
useful probably does not need much  advance notification to the user
community, just documentation is sufficient.   Changing the error codes
to match embedded probably requires significant prior notification.

I think the 10.1 tests are a good way to try to understand the impact
changes might have on existing applications.
I've started to think maybe instead of strictly checking for behaviour
depending on server version we should just change them all to work with
10.1, 10.2 and future versions like we ask our users  to do with their
applications.  If nothing else,  it would make for good sensitivity

>If this seems like a good list I'll create a wiki page.
Thanks Dan!

View raw message