why to (not) support "older" compiler versions

[Mathias Lang via Digitalmars-d]

On Tuesday, 3 November 2015 at 08:08:28 UTC, yawniek wrote:
> i have seen many PR's and also Forum entries that deal with the 
> problem of newer features of the compiler not being able and 
> then patching or working around that to support older compiler 
> versions.
>
> since it is really easy to keep up with compiler versions and 
> even switch
> (and not many features are being removed from dmd) what are 
> good reasons to keep backward compatiblity?
>
> the latest example i saw was replacing groupBy by a loop to 
> keep compatiblity with 2.066.
> while not a big thing, it adds up.

Why do we keep backward compatibility ? The answer is dead 
simple: people need it.

The assumption that it's easy to upgrade is totally false. 
Upgrading to a newer version is costly. You need to test it, 
maybe repackage / redeploy new applications / library and monitor 
that every still runs smoothly. This has a cost, and the bigger 
you are, the higher the cost.


> since still a lot of useful features do get added into phobos 
> at a fairly fast pace,
> would it not be better to to keep targeting just the two most 
> recent versions and moving
> the ecosystem a little bit further.

Unless the new release has a definitive advantage for you, like a 
much-needed feature, that cost isn't justified, and you're better 
off spending time / money on things that matter to you (like new 
features).


> For people entering the world of D it would be much more 
> encouraging to read a lot
> of concise code using all the nice features we have instead of 
> just lipstick'd C.

If 2.066 is just lipstick'd C to you, you had already spend too 
much time having fun with D and not enough using C ;)

One thing important for people entering the D world (or any 
world) is as little friction as possible. And if things don't 
work out of the box it's a lot of friction. Backward 
compatibility help with that as well.