On 11/12/2016 02:20 PM, Basile B. wrote:
> On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote:
>> Glad to announce D 2.072.0.
>>
>> http://dlang.org/download.html
>>
>> This is the release ships with the latest version of dub (v1.1.0), comes
>> with lots of phobos additions and native TLS on OSX.
>> See the changelog for more details.
>>
>> http://dlang.org/changelog/2.072.0.html
>>
>> -Martin
> 
> Sorry another regression:
> 
> https://issues.dlang.org/show_bug.cgi?id=16682
> 
> I don't know if it's a real regression, maybe the PR that breaks dfmt is
> legit but at least
> - you (you == dlang team as an entity) could start a deprecation period.
> - the community could detect that before.

Thank you for the report! Will add that to required reverts in a moment.

Both points you have mentioned indeed can and should be addressed.

On 11/11/2016 09:36 PM, Nick Sabalausky wrote:
> On 11/11/2016 08:30 AM, Dicebot wrote:
>> On Friday, 11 November 2016 at 13:21:40 UTC, Nick Sabalausky wrote:
>>> Run the new dmd. If it fails, either fix your code or go temporarily go back to the old dmd until you can fix your code.
>>
>> D will never be considered production ready as pong as this attiude remaind. Your described scenario in practice works like this:
>>
>> - You decide to delay fix until you have time to investigate
> 
> I've gone through a lot of compiler upgrades on a lot of D projects, and in my experience, this "investigate and fix for the new dmd" has always been trivial (aside from one instance where Phobos's standard function deprecation policy wasn't followed).

Speaking of Sociomantic experience, practice has shown that any breaking change that requires 5 min fix for any given project can easily take from weeks to months (!) before all maintained interdependent projects are updated. With deprecations it is not a problem at all because everyone moves on using own schedule caring only about hard time limit. With _any_ sort of immediate breakage it is pain because now upgrade both becomes urgent and needs to be explicitly synced between all developers.

It is simply another side of "nine women can't make a baby in one month" thing. Best way to scale large teams is to split them so that amount of people involved in any specific process is minimal, otherwise even trivialities escalate exponentially under weight of communications. And with software development "large" starts pretty small.

> Some things should certainly have a smooth transition path (like above, when replacing a Phobos function with a different one), but really, not everything needs to be.
> 
>> - Half of users of your library you (or your colleagues) complain that
>> they can't upgrade their projects because you areso slow
>> - You desperately find time to do required fix which proves bavkwards
>> incompatible
> 
> AFAICT, That's not the case with this particular cycle detection matter.

Yes, but this is mentality I am talking about. In vast majority of cases providing smooth deprecation path is trivial - replacing `error` call with `deprecation` call in DMD patch, marking symbol as deprecated before removing in Phobos. In some of PRs I have found while checking last breakage, amount of time spent on discussion if it is OK to make a change was 10x more than amount of time that adding deprecations would take. It is waste of everyone's time!

We need to establish attitude were doing deprecations is a no-brainer, like providing unittests for new functionality already is. Not because some weird corporate ass demands it but because it is simple and benefits the whole dub ecosystem.