Re: Avoiding Application Re-test

simon(at)2ndquadrant(dot)com (Simon Riggs) writes:
> Every time we introduce a feature that changes output, we just put an if
> test in saying sql_compatibility = X, (the release we added feature).
>
> Straightforward, futureproof. Cool.

This is somewhat like the way that some shells try to emulate others;
for instance, zsh tries to emulate "sh" or "ksh" when invoked by those
names.

There are two problems with this:

a) The conspicuous phrase, "try to emulate"

Which leaves open several questions:

- What if we can't?

- What about when we don't want to (e.g. - because the new
version has a new behaviour that we *DO* want)?

- What if some semantic change takes place that we didn't
realize should have been open to the "try to emulate"?
Such as, where there's an ordering change...

b) It requires adding a new, not-previous-existant effort to
classify changes and put in logic to allow controlling whether we
use "legacy logic" or "new logic."

That seems likely to get mighty messy to me, requiring
"blabbering" control code throughout the code base.

I don't think we actually get the "future proofness" that you're
suggesting. It would be nice if we could, but that seems unrealistic.
--
let name="cbbrowne" and tld="linuxdatabases.info" in String.concat "@" [name;tld];;
http://linuxfinances.info/info/spiritual.html
Rules of the Evil Overlord #204. "I will hire an entire squad of blind
guards. Not only is this in keeping with my status as an equal
opportunity employer, but it will come in handy when the hero becomes
invisible or douses my only light source."
<http://www.eviloverlord.com/>