[Dlang-internal] Regression control & breaking changes policies

[Walter Bright via Dlang-internal]

On 12/9/2016 11:32 PM, Martin Nowak wrote:
> 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.

Then preview it is.


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

Then we're still faced with reverting the deprecations, as what happened.


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

That's disappointing, but ok. It will take a while for us to explain how it 
works and get acceptance of it. The threads here are abundant evidence for that. 
But by getting it in, even under a switch, means we can make a credible case 
that D is a solution for memory safe programming, which is a huge deal.


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

See above.


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

True, but it's still the most practical way, given our large user base.


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

It is finished. There are no known issues with it.