[Dlang-internal] Regression control & breaking changes policies

[Dicebot via Dlang-internal]

On 12/07/2016 05:34 AM, Walter Bright wrote:
> On 12/6/2016 5:54 PM, Dicebot wrote:
>> On 12/05/2016 03:10 AM, Walter Bright wrote:
>>> The table makes sense and looks right. But there's a problem with the
>>> return scope changes. It's just too much to just wholesale deprecate
>>> things all at once.
>>
>> It will need to happen at some point anyway. Without having those
>> deprecation implemented we can't even know how much existing code is
>> affected.
> 
> That's the point of the flag. It can be done on the user's timescale,
> not ours.

Flags don't allow for user timescale, only deprecations do. Flag can be
one of possible preview options but you can't start adjusting your
projects while it is in flag mode because that will break all downstream
projects that depend on yours (and don't want to enable the flag yet).

>>> People need time to ease into it, not be faced with
>>> a pile of diverse deprecation messages.
>>
>> We can introduce `-preview=XXX` flag for that purpose but the key thing
>> is that it still has to use deprecations and not errors for all scope
>> related changes. Otherwise you introduce dangerous disparity between
>> what gets previewed and what will eventually become the default.
> 
> I agree, but it doesn't have to be deprecations until the flag becomes
> the default.

Practice has shown that if it isn't deprecation from the very start, you
won't change it later and it will be me or Martin adjusting it in hurry
mode before release. I don't want that. For you as original implementor
there should be no difference in effort required between implementing
checks as deprecations or errors - as such, I can't find any excuse to
not do it from the very beginning.

>> 2) You must not use the very same flag for bug fixes as an excuse to not
>> bother of deprecations. https://github.com/dlang/dmd/pull/6290 is the
>> last one remaining now there was no justification to merge it in first
>> place.
> 
> There isn't a hard line between what is a bug and what is not. It'd be
> nice if there was. Pretty much all of these fall under fixing unsafe code.

It is irrelevant, you have misread the statement. Breaking change
requires deprecations, no matter if it is a bug fix or not. You can add
additional helpful information via -transition flag but it still has to
be deprecation and using any kind of flag can't be an excuse to not do so.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puremagic.com/pipermail/dlang-internal/attachments/20161212/fdc76487/attachment.sig>