db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)
Date Fri, 31 Mar 2006 17:02:10 GMT
Thanks, David. I think this discussion is raising some interesting issues.

David W. Van Couvering wrote:

>> 2) Bug fixing policy.
>> I think that the Exceptions section should say explicitly that "It is 
>> OK for minor releases to fix bugs in our implementation of the 
>> standards, even if those fixes break existing applications."  
>> Bugfixes can and do break applications and so violate the cardinal 
>> rule. Here are some more examples:
>> 2a) Wrong query results. The correct results may break applications 
>> which are either unaware of the problem or which have already written 
>> compensatory logic to patch over our error. Correct results may slow 
>> down the query's performance and the customer may consider this 
>> degradation intolerable.
> Ooh.  I can tell you speak from experience.  I would actually argue 
> that this is not acceptable.  You can't just break applications 
> without warning.  What I have seen in the past is you provide the user 
> to enable the old or new behavior through some kind of flag, e.g. 
> derby.use.old.broken.behavior or derby.use.new.fixed.behavior 

I am glad that we are bothering to make these rules explicit. In a 
previous life at Sybase, we solved this problem by adding special 
tracepoints for big, important customers who relied on old, incorrect 
behavior. As I recall, we didn't know up front who would object to a 
correction. The tracepoints went into patch releases based on customer 
dissatisfaction with the last minor release.

Do you think the Sybase model will work for us? Or do we need to add 
tracepoints to the minor release as we fix the incorrect behavior? Maybe 
it is not good enough to add a master tracepoint with the semantics 
"Simulate all incorrect implementations of the standards fixed in this 
release, X.y." Customers may want something more granular, say, a 
tracepoint per obnoxious correction. Over time, these tracepoints will 
pile up and the code will  become a more exciting pinball machine. What 
are your thoughts?

>> 2b) Our DRDA implementation may incorrectly transport datatypes not 
>> recognized by DRDA. Conforming to the DRDA spec may mean removing 
>> this transport capability and breaking applications which select the 
>> unsupported datatypes.
> I think it would be unacceptable to remove unsupported datatypes, even 
> if they are not spec compliant.  Again, you use versioning and 
> capabilities negotiation to change in a compatible way.  For example, 
> if someone has an itch to support a network client that can only 
> handle the types specified in DRDA, and the network client today 
> supports non-standard types, then we should provide an option to run 
> in "standard-DRDA" mode and disable those types.
> If we want to add new, non-standard types, then we should only support 
> these types if the client explicitly says it can handle them.

I'm happy with this approach. I would like to see the wiki state these 
rules explicitly.

>> 3) Client/server compatibility.
>> I would expect to find these rules spelled out on the wiki page. It 
>> is not clear to me that you can deduce client/server compatibility 
>> from the cardinal rule. Are these the rules?
> I did add a note based on Kathey's comments.  I think you *can* 
> achieve this by declaring the right interfaces as Stable or Private 
> Stable, but I agree it's good to call it out.


>> 3a) A major release number defines a family of compatible Derby 
>> clients and servers. Derby clients and servers can interoperate 
>> provided that they share the same major release number. Say that an 
>> application currently runs using a client and server from the same 
>> family. The application will continue to run if the client upgrades 
>> to the next minor release. The application will also run if the 
>> server upgrades to the next minor release.
>> 3b) We strive to minimize incompatiblities across release families. 
>> However, we do not guarantee that a client will interoperate with a 
>> server having a different major release number. If an application 
>> upgrades its client to a new major release, the server may have to 
>> upgrade to the new release family too. Similarly, if an application 
>> upgrades its server to a new major release, the client may need to 
>> upgrade too.
> I think this is implied in the definition of Stable and Private Stable 
> interfaces, and by ensuring that all interfaces that the network 
> client depends upon are marked as either Stable or Private Stable.
> I can imagine us providing this kind of wording in our documentation, 
> but I am not sure if it is required here, I think it's already covered.
> I think your wording does add some clarity about when changes may 
> occur, and I may add that to the note about this that I copied from 
> Kathey's email onto the Wiki page.


View raw message