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.
