Kathey Marsden wrote:
[snip]
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?
I think of jar file names as an interface, but the others as signs of
a regression in functionality. And yes, we should identify the
stability we guarantee for file names. Other file names are the log
file name ("derby.log"), the
File formats are also interfaces, such as the message log file
format, the database file format, and the transaction log file format.
The other things you mention don't seem like interfaces but are
measures for whether the product has regressed in some way.
Also, there are gray areas
.
- Changes to things like error codes, sqlstates and system tables.
These are interfaces, but since they're not documented, the should be
considered "internal" and those no stability is guaranteed.
- Changes to make client match embedded for implementation defined
behaviour.
Well, that's an interesting one. The trick is as you do this, you
may be changing the client interface in incompatible ways, even if
you get better consistency across the two versions.
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.
Agreed
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 agree, but we should treat incompatibilities with different levels
of severity depending upon our guarantees of stability we document
(initially in the Wiki page, but ultimately I'd like to see this made
available as part of our overall documentation).
By the way, we at Sun have to provide this kind of documentation to
our own internal architectural review committee. We have to
guarantee stability even if Derby can not, so that other projects can
safely depend on us. Having something like this for Derby would be
very reassuring for *our* customers I can tell you that.
David
If this seems like a good list I'll create a wiki page.
Thanks Dan!
