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.
