Release D 2.072.0

[Dicebot via Digitalmars-d-announce]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-announce/attachments/20161115/0e75fc57/attachment.sig>