[Dlang-internal] Regression control & breaking changes policies

[Sebastien Alaiwan via Dlang-internal]

On Wednesday, 7 December 2016 at 01:56:15 UTC, Dicebot wrote:
> THERE IS NO SUCH THING AS MINOR REGRESSSION
> THERE IS NO SUCH THING AS MINOR REGRESSSION
> THERE IS NO SUCH THING AS MINOR REGRESSSION
> THERE IS NO SUCH THING AS MINOR REGRESSSION
> THERE IS NO SUCH THING AS MINOR REGRESSSION

I couldn't agree more.

Compromising on "minor" regressions maintains the whole codebase 
in an unstable state, as there's no more guarantee that the 
feature I rely on today will not be "broken in a minor way" 
tomorrow to enable a "better" feature.

This is equivalent to disabling the tests that you've just broke 
to force your feature into the codebase (BTW allowing any kind of 
regression also make it a lot harder to guarantee that the 
codebase is actually improving).

Users have no global vision of the product, and if an update 
breaks their workflow, they will only see the regression. They 
won't be able to appreciate the fact that as a whole, the product 
might be better today. In one word, each time a compiler upgrade 
forces the users to modify their codebase, some of them leave 
(and god kills a kitten).

However, only simple policies stand the test of time ; if you 
want to establish a policy and need to argue over it, you've 
already lost the war.

The only regressions you might be able to forbid are the ones 
that are detected by an authoritative test suite that anyone can 
run before submitting patches, allowing to establish the 
brokenness of a feature in a non-ambiguous way.

It's a lot easier to enforce the authority of a test suite than a 
systematic-revert policy (with which I would totally agree!).