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 19:17:47 GMT
We already have to cross this bridge for the next release of Derby. 
DERBY-280 is a correctness bug, which while not fixed, was patched. This 
changes the behavior of a family of queries which were returning wrong 
results. What should we do:

1) Add and document a tracepoint allowing customers to get the previous 
incorrect behavior? Please say no. I think we all believe this is a 
crummy solution.
2) Document the changed behavior in the Release Notes. If an important 
customer complains, then we can evaluate how to satisfy that customer in 
a follow-on release.
3) Something else?

-Rick

David W. Van Couvering wrote:

> I agree this sounds like a terrible model.  But we have to accept 
> reality, we *are* going to have bugs.  And if we can't fix those bugs 
> in a backward-compatible way, then it is more than likely that some 
> Big Huge Customer will refuse to upgrade.  I saw that at Sybase as 
> well. Perhaps the cost of supporting older codelines is ultimately a 
> better choice for our product than the spaghetti of micro-compatbility 
> if-statements and weird "behavior plugins" in the code.
>
> I don't have an easy answer.  I agree we should strive for 
> correctness, and perhaps we'll just have to cross that bridge when we 
> come to it.  I think Rick's caveats are valuable, but I don't want 
> them to be a loophole that we then use to feel we have more free rein 
> to break compatibility.  But, saying that, knowing this lot I suspect 
> we don't have to worry about this, you can't sneeze around here 
> without someone worrying whether than sneeze was compatible with your 
> last sneeze :)
>
> David
>
> Daniel John Debrunner wrote:
>
>> Rick Hillegas wrote:
>>
>>
>>> Thanks, David. I think this discussion is raising some interesting 
>>> issues.
>>>
>>> David W. Van Couvering wrote:
>>>
>>>
>>>>> 2) Bug fixing policy.
>>>>>
>>
>>
>>> 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?
>>
>>
>>
>> I think it's a terrible model. This moves the project into a state where
>> the number of possible execution time modes will increase rapidly,
>> causing nightmares for those who have to support it or answer questions
>> on the user list.
>>
>> For any change we as a community should be confident it is the correct
>> change.
>>
>> [disclaimer - I was at Sybase during those times ]
>>
>> Dan.
>>


Mime
View raw message