Ghosting a language feature

[Avrina]

On Tuesday, 22 September 2020 at 04:38:37 UTC, Walter Bright 
wrote:
> On 9/21/2020 6:08 PM, Mike Parker wrote:> D 2.094 is a
>> And if I want to upgrade from 2.094 to 2.095, but the new 
>> version introduces a regression that blocks me, that 
>> regression might not be fixed until 2.098. Now in order to 
>> upgrade I need to deal with the changes and possible 
>> regressions in multiple milestone realeases because there's no 
>> long-term patch support for 2.095.
>
> I agree that no long-term patch support is a problem. But it's 
> mainly the result of our team being small, not having a 
> different release scheme. There's nothing really preventing a 
> regression fix from going back into any particular release 
> except someone actually doing it.

This sounds like an excuse. There are smaller languages with 
smaller teams that have better backwards compatibility and 
support for it than D does.


> Needing patch support for various versions could be an ideal 
> thing that companies that need it can supply funding for.

How would extra funds help? There's more than one way to solve a 
problem. One such solution would be changing the release scheme.

For example, if a patch needs to be backported for the last 2 
years. You'd have to backport that patch to 12 different versions 
of DMD. If only 2 major releases of DMD were released a year that 
would drop by 66% to 4. Backporting a patch to 4 versions is 
significantly easier and requires less work (and funding :D) to 
actually do.

So the release scheme definitely has an impact. If there's a 
major spec release every 2 years, a patch would only have to be 
backported to 2 versions to support the last 4 years. Where as 
how many versions would you have to backport to to support the 
same amount of time? 20? 30? Who's going to do that? That's a 
waste of time because of the versioning scheme being used.