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: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)
Date Fri, 31 Mar 2006 18:04:46 GMT
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 :)


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.

View raw message