Kathey Marsden wrote:
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?
Those are good to consider, maintaining the jar file names for sure. Jar
growth and performance in general are interesting since they are not
functional regressions. I think we all have the itch to have Derby used,
if we made it big and slow people wouldn't use it.
Also, there are gray areas
.
- Changes to things like error codes, sqlstates and system tables.
- Changes to make client match embedded for implementation defined
behaviour.
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.
Yes, depends. I would say ok to change any SQL state for a compilation
error, I can't see applications relying on specific SQLStates related to
a syntax error. But changing the error code for a deadlock or constraint
violation would impact applications.
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
training.
I think the running 10.1 tests against 10.2 in various forms has been a
good and useful exercise. I'm struggling thinking how to automate that,
given we did see sixty odd failures in some configurations.
Dan.
