[Dlang-internal] Regression control & breaking changes policies

[Dicebot via Dlang-internal]

Moving the discussion from the PR 
(https://github.com/dlang/dmd/pull/6290#issuecomment-264706485) 
for better exposure.

Recently I tried to get a bit more involved with preparing and 
maintaining releases but I see that there are a lot of responses 
that imply that at least some of my methodologies are either 
misunderstood or disapproved. So probably better to discuss it to 
see if we can get on a common ground.

There are several fundamental goals I'd like to pursue:

1) At any given point of time the master branch should be as 
close to release quality as possible
2) Lack of implementation quality in merged PRs should not become 
burden of maintainers
3) Deprecation system has to be used for any breaking changes to 
the point it can be relied on

(1) and (3) are supposed to make life of commercial users easier 
directly, (2) aims for the same goal by reducing maintenance 
burden and thus improving release fixup latency. Those all are 
areas that are currently lacking a lot in D development process 
and that is rather painful.

Keeping this goal list in mind, I want to propose some consequent 
practical applications:

a)

     If any breaking change is detected in both master and stable 
that doesn't
     come at least with detailed explanation in the changelog, it 
has to be
     reverted unconditionally.

This is a very simple and harmless way to improve on goals (1) 
and (2). I have noticed that reverting of merged code is often 
viewed as something damaging and even disrespectful - it isn't! 
By reverting a PR one immediately fixes the problem in relevant 
branch causing less trouble for other developers while providing 
more valuable information (and regression test case) to revive 
original PR. Compared to trying to fix the problem in place it 
also puts much less stress on developer as one can take all the 
time needed.

Similar reasoning applies to fixing regressions in point releases 
- it is not worth spending time on that unless fix is immediately 
obvious and trivial. World won't burn if those fixes will get 
delayed a bit, but providing public release with minimal amount 
of issues known is urgent.

b)

    Any breaking change that causes compile-time error has to 
undergo
    deprecation stage. It applies to bug fixes too. If breaking 
change changes
    code semantics but keeps compiling, it has to provide 
`-transition=XXX`
    diagnostics to help with migration AND changelog entry 
explaining what to
    look for.

This is a long standing source of complains from me but I had no 
idea that purpose of `-transition` flags is not widely obvious. 
Martin Nowak has drawn this nice table that explains it better:

before change  |  after change | transition process
===================================================
valid          | invalid       | deprecate-then-error
invalid        | valid         | none
invalid        | invalid       | none
valid          | valid         | -transition=feature to find 
semantic changes

One key thing about this is that adding deprecation is in most 
cases trivial and adds no extra effort if done right from the 
beginning. Tracking changes and fixing it later, on the contrary, 
is a killer for combined productivity.