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