db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: Derby regression/compatibility
Date Fri, 10 Feb 2006 05:14:39 GMT

Kathey Marsden wrote:

> 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.


> 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.


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

View raw message