Release D 2.072.0

[Jonathan M Davis via Digitalmars-d-announce]

On Friday, November 11, 2016 14:36:59 Nick Sabalausky via Digitalmars-d-
announce 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).
>
> 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.

In general, I agree, but it can cause problems when something works with the
last release and not the master branch (you can't always avoid that, but
it's far better to if you can), and even when just considering releases,
having stuff work with one release and not the next can cause serious
problems when you're providing a library for someone else or dealing with
multiple programs where you can't just upgrade everything at once. Dicebot
talked about problems along those lines at Sociomantic in his talk at dconf
2015:

http://dconf.org/2015/talks/strasuns.html

It's a sucky scenario to be in, but you don't always have a choice -
especially in a corporate environment.

Another fun problem is when you try and support multiple versions of
dmd/druntime/phobos with the same project (like vibe.d does). Hard breakage
can make that difficult (though not impossible).

I don't think that it's always possible or reasonable to provide some kind
of deprecation path or to smoothly transitition from one behavior to another
(particularly when dealing with certain types of bugs), but if we don't at
least try and mitigate those types of problems, we're going to have problems
with folks who do not have the luxury of being able to simply update their
code base for the new release, even if the changes themselves are trivial.

- Jonathan M Davis