Release process and backwards compatibility

[Jesse Phillips]

On Saturday, 9 March 2013 at 06:22:15 UTC, deadalnix wrote:
> Many things can be done to mitigate that stuff.

Thank you,

Now we need to come up with ways to help facilitate making these 
changes.

> The first, obvious one, is to provide a version of the compiler 
> without the fix (bug with other fixes that don't break most 
> code).

This is supposed to be addressed by the new release process. I 
don't think helps in mitigation, it is avoidance which has some 
positives in its own right.

> A second thing to do is to adapt phobos to take rvalues at 
> several places. (This have the problem that ranges have 
> unspecified behavior when passed by value).

Phobos makes use of itself and so a disruption in the language 
will cause Phobos to show issue. If we adjust Phobos to work with 
itself/unittests, things we miss are likely because we didn't 
have a complete set of unittests on behavior?

Since unittest won't cover every case, maybe we could try a tag 
on the bugzilla entry to indicate Phobos was changed as a result. 
A comment including the need changes is added. When reviewing a 
pull request for such one would theorize on possible other 
implications and can request further changes if needed.

Something similar can be done for Phobos changes, as accepting a 
range by rvalue could have other implications and thus would need 
a good statement of breaking change.

> Finally, an useful error message, with a workaround proposal 
> would be welcome,
> Error, range used as lvalue. You may want to do BLAH to solve 
> that.

Yeah review should look for good error messages. Though we may 
want to be careful about suggestions (too many options, too long 
to describe, only relevant to broken code and not code originally 
incorrect).