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.

On Tuesday, 22 September 2020 at 14:23:51 UTC, Avrina wrote:
> 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.

To add on to that, every version a patch is backported to has potential to cause it's own bugs and regressions. So if you have 20 or more versions you'd have to support for a period of 4 years, that's just not feasible, regardless of manpower or funding.

On Monday, 21 September 2020 at 09:06:50 UTC, Mathias LANG wrote:
> But still, people complain. And many core contributors, myself included, will heavily weight against breaking change. So why the apparent disconnect ?
> Once again, the person that managed to put it together best was Don Clugston. He mentioned it in his talk @ DConf 2013.

I think a big source of problems when introducing breaking changes was that it wasn't really tested on any prominent codebases, so the only breakage index was D unit tests. As far as I know, DMD is tested against top N dub packages at the moment, so before you break something for users you can figure out how much of an effort it will be. There is a difference between breaking top packages and breaking a single package that only few people use.

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 different languge than D 2.074. How many people can say how > they differ?
> I can't say, either, without looking at the changelog. But does it matter? If a particular feature is of interest, can't the changelog suffice?
>
>
>> 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.
>
> Needing patch support for various versions could be an ideal thing that companies that need it can supply funding for.

Delurking because this is a really important issue.

Unfortunately that doesn't really work. You need to have designated long-term support releases. There doesn't need to be very many of them, but they must exist.
Currently the most recent one is called D1. :)

What I think most of the community doesn't realize with this issue, is that just because a body of code needs compiler patches, does *not* mean that any development is happening. I didn't appreciate this until it happened to me.

Here's what happened in the dying days of Sociomantic. All development ceased on the project. But, the apps still needed to run, until our contracts with existing customers ran out.

But then the Linux version we were running on, ran out of support. We had to upgrade the servers to a supported Linux version. But we could not do this. All supported Linux versions required position independent code.
Simple, just add -fPIC to the Makefile, and recompile.

I wish.

Unfortunately there was a wrong-code bug in the compiler, which happened if compiled with -fPIC. This was only fixed in the most recent compiler release.
So, we have to jump forward many releases. And these releases included some huge deprecations. When I did this, the compiler spat out over 3000 errors. In many of these cases the required changes were far from trivial. Most of the team has left by that point, so I have to make the changes and hope I didn't break something in the process.

Then, after making all these changes, I discover there's been a regression before the -fPIC fix. The regression is fixed since the last release. So the only compiler that works is the nightly build of dmd. This is so unprofessional it blows my mind.

Remember, all the budget allowed for was, add -fPIC and recompile.

Back in 2007, D had a long-term support release. It needs a more recent one.
That's not a luxury, it's a necessity. You're not a serious language without one.
Just *one* LTS at any given time would be a good start.

On Friday, 25 September 2020 at 15:49:54 UTC, Don wrote:
> Back in 2007, D had a long-term support release. It needs a more recent one.
> That's not a luxury, it's a necessity. You're not a serious language without one.
> Just *one* LTS at any given time would be a good start.

Nice to see someone agree with a position I've always had. I like that Debian has a stable release that is very conservative.

For a server-compiler it might be a good idea to backport to whatever version of the compiler is the "default" at the Debian stable release.

On 9/25/2020 8:49 AM, Don wrote:
> Unfortunately there was a wrong-code bug in the compiler, which happened if compiled with -fPIC. This was only fixed in the most recent compiler release.
> So, we have to jump forward many releases. And these releases included some huge deprecations. When I did this, the compiler spat out over 3000 errors. In many of these cases the required changes were far from trivial. Most of the team has left by that point, so I have to make the changes and hope I didn't break something in the process.
> 
> Then, after making all these changes, I discover there's been a regression before the -fPIC fix. The regression is fixed since the last release. So the only compiler that works is the nightly build of dmd. This is so unprofessional it blows my mind.
> 
> Remember, all the budget allowed for was, add -fPIC and recompile.
> 
> Back in 2007, D had a long-term support release. It needs a more recent one.
> That's not a luxury, it's a necessity. You're not a serious language without one.
> Just *one* LTS at any given time would be a good start.

This is the first time I've heard of your travails on this.

I'm sorry this burden fell on you. You needed two patches to an older compiler. There's only one way this can happen - someone has to apply those patches to the older compiler, and test the result.

Having a LTS version does literally nothing to make this happen. To make this work, an engineer has to be available to make it work, someone that can "add patch X to release Y". The only way that can happen is for someone to volunteer to do it, or for someone to be paid to do it.

Another problem is there are what, 20,000 PRs for dmd? Which ones need to be put in the LTS version? Who decides? The only workable scheme I can think of is the customer who needs X (every customer has different issues that need attention) needs to find or fund an engineer to do it. This is why D is open source.

All I can helpfully suggest is we (the topic of this thread) avoid removing harmless features just because they are obsolete. This will reduce (hopefully eliminate) the redesigns necessary to move forward.

On Thursday, 1 October 2020 at 09:49:20 UTC, Walter Bright wrote:
> The only workable scheme I can think of is the customer who needs X (every customer has different issues that need attention) needs to find or fund an engineer to do it. This is why D is open source.

Clearly not. There are at least two options:

1. Do as C++ compilers do, support multiple language-versions to the same backend. The easiest way to do this is to have a shared mid-level IR and ship with multiple front ends.

2. Label a specific Linux distribution as supported and specific compiler front ends, and make sure that all those work on the last few major releases of that Linux distribution.

Then plan for it. It is a matter of strategic choices. Not at all difficult to achieve. (Just refuse changes that jeopardise the core strategy.)

Who decides now?

The people deciding now have no recourse, if an LTS version existed, they would have.

See here: https://github.com/dlang/dmd/pull/9289#issuecomment-468633169

    "" It seems that the projects listed in buildkite don't suffer from this bug so I suggest we just swallow this pill and merge this. ""