[Dlang-internal] Regression control & breaking changes policies

[Martin Nowak via Dlang-internal]

On Wednesday, 7 December 2016 at 03:34:02 UTC, 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.

Deprecations already provide for that. As a user you can delay 
updating a release for a short while, then you can still ignore 
or even silence deprecations until you have time to deal with 
them. That's the whole point of deprecations, they inform you 
than sth. is going to change and give you a timescale until when 
it needs to be fixed.
Hiding stuff behind a switch doesn't do much, but delaying the 
time until we inform people.
If you want provide a preview, we can build preview releases.

>>> People need time to ease into it, not be faced with
>>> a pile of diverse deprecation messages.

Maybe we could improve our deprecation output to classify the 
deprecation categories with some numbers, limit the amount of 
deprecations shown per category, and allow to silence specific 
deprecations.
The important difference, it's opt-out not opt-in, and doesn't 
add a pointless delay.

Also I doubt that anyone is using those switches.
Only found a 2 D user projects on github using DIP25.
https://github.com/search?l=Makefile&p=1&q=dip25&type=Code&utf8=✓
https://github.com/search?utf8=✓&q=dip25+extension:sdl+extension:json&type=Code&ref=advsearch&l=&l=

>> 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.

That's just extra confusing. Also it doesn't work for dub, where 
one user might want to use that feature but a dependent library 
isn't yet compatible,
Again deprecations work as designed here (as in any other 
language) and it remains unclear why you need something different.

>>> Having -transition=safe makes that practical, and also 
>>> ensures time to
>>> correct any unrecognized issues with it.

That's quality of implementation and our testing duty. Also since 
hardly anyone will test that switch, the main effect it has has 
is delaying the time until the issues pop up.

>> 1) `-transition` flag is not for this purpose. You want this 
>> behavior -
>> please introduce new flag group, for example `-preview=scope`. 
>> Desire is
>> legit but you have to use a different flag for such purpose.
>
> It originally was just `-safe`, but I got a lot of flak for 
> that and pressure to use `-transition`. I don't really care 
> what the flag is. It just needs a flag.
>
> I doubt users will really care either if it is -safe, -dip1000, 
> -transition=safe, or -preview=safe.

Well -preview is really what this is about, but I'm convinced 
we're better off to provide preview releases/build instead of 
merging unfinished features into master and the next release.