D has become unbearable and it needs to stop

[Martyn]

On Tuesday, 13 June 2023 at 14:17:33 UTC, deadalnix wrote:
> On Thursday, 8 June 2023 at 13:38:20 UTC, GrimMaple wrote:
>> I usually try to stay more silent (on the form at least), but 
>> I think I reached my boiling point. I've been a (self 
>> employed) full time D developer for almost 2 years now, 
>> developing quite a large codebase of personal closed source 
>> projects, as well as adopting some 3rdparty code like dlangui. 
>> And my life has become particularly miserable in the last half 
>> a year or so.
>>
>> [...]
>
> Case in point:
>
> https://issues.dlang.org/show_bug.cgi?id=23989

Interesting...




Anyway, this is a general question for all, and I understand I am 
(likely) showing my n00bness as a D developer.

(Afterall, one of the reasons I am skeptical using Dlang for 
production is precisely this reason... no LTS and, more 
specifically, mangling of libraries tested under different dmd 
builds)

For example.. lets say:-

I have created a D application using DUB. So far, so good. It 
builds with the latest version of dmd I installed earlier today 
(2.104.0)

Ok, now I need to use some libraries. DUB is great for this! 
However, when I search for packages, how do I know which version 
they support?

```
    2.104.0?
    2.103.0?
    2.102.0? (???)
```

Are we expecting maintainers of these libraries to keep them up 
to date monthly? Lets be honest.. if I need to include 3 DUB 
projects into my application then what are the chances they have 
been tested on 2.104.0? It is highly unlikely. The next question 
is - what version should I be using? Atleast 4 versions old?

One DUB package might have been updated 4 months ago. While I can 
predict the version they last used, it does not mean thats that 
the version tested by the maintainer. Should I have to predict 
this? Should I have to look at their code? Each DUB package have 
their own versioning which does not help, either.

Now, imagine the difficulties of an application with 3 or 4 DUB 
packages. Each library being released/updated at different times 
and lord knows what version they were last tested on. Will they 
all work with 2.104.0?

Because of potential breaking changes for each new release... 
could I end up with ProjectA being OK but not another, while 
experimenting with different dmd versions?

There is a reason why LTS releases exist. Look at other 
languages. Java, .NET, C++. Look at other projects like Linux or 
Blender. Could you imagine Blender users going by monthly builds 
only. Blender would fall apart and fast!

Again, if we had LTS builds, our libraries can target those 
specifically. It also makes it easier to maintainers to plan 
ahead for the next LTS. As my previous post suggested, the 
version of the libraries can start with the LTS version. It makes 
it so easy to know if your version is supported, etc.

Just my 2 cents and I apologise if I am really missing the point. 
I am sure atleast some of this lands with a number of people.