So D will have LTS or not?

harakim harakim at gmail.com
Wed Jul 5 08:09:17 UTC 2023


On Monday, 3 July 2023 at 16:04:27 UTC, Martyn wrote:
> On Monday, 3 July 2023 at 12:43:30 UTC, bachmeier wrote:
>
>> Currently **we have many compilers in use out in the wild**, 
>> and there are no bug fixes being ported to them from later 
>> releases. (Has a single bug fix been ported from 2.104 to 
>> 2.101, even though they're only six months apart?)
>
>     We currently have a release cycle, released often, like so:-
>      2.101 --> 2.102 --> 2.103 --> 2.104 --> etc
>
> I do not expect any ~bug fixes~ for previous releases. After 
> all, this release process, to my knowledge, is **purely 
> sequential**. Keep moving forward type approach. Whatever the 
> latest release is, is what's being advertised/presented on the 
> dlang download page. It is also the default compiler when using 
> the *.sh installer.
>
> The problem, at its core, is that a new release could, 
> potentially, cause a *breaking change* yet we push forward the 
> it's new/latest release.
>
> As a result, and as you put it, you end up with many `compilers 
> out in the wild` which does not help application or library 
> developers using D to get stuff done.
>
> A higher level developer that is trying to create a GUI 
> application, or a Website, or a Worker app, etc, should not be 
> presented with all these releases. They are also left in the 
> dark when adding a DUB dependency. What version was that 
> library tested on before its latest release to DUB?
>
> By default we are encouraged to use the latest release. Are we 
> expecting library maintainers to keep up-to-date on a monthly 
> basis all because "this now breaks that" attitude?
>
> The core team, in my opinion, need to reach a point of saying 
> "Okay, time for a new TLS release" and spend the next few 
> releases cleaning up and making it stable. Once happy (say 
> release 2.109.0) we branch off with a new TLS stable release. 
> Lets call it "TLS23" (as in it was released in 2023)
>
> TLS23 is the main release, and should be the main highlight of 
> the download page. Sure, latest D releases can still be 
> advertised, but to use at your own risk, etc.
>
>
>> Those in power are saying that all bug fixes would have to be 
>> ported back to an LTS, and until the manpower for that is in 
>> place, we have to stick with the current mess
>
> Again I know this is not a simple job (as I mentioned in my 
> previous post) - it will require a few people to handle TLS 
> management.
>
> However I do not believe `all bug fixes` need to be placed back 
> into the current TLS.
>
> Yes, the current TLS branch will start to fall behind as newer 
> releases are out (2.110, 2.111, 112.0, etc) but some bug fixes 
> wont be relevant to the current TLS. It all depends on what the 
> bug fixes are. I would say **important** fixes, like major 
> vulnerability issues should be factored into the current TLS 
> branch.
>
> Considering, in recent D meetings, has been the idea of pushing 
> Dlang on social media, etc, to try and entice new users to the 
> language.. or to, atleast, get people talking/sharing about D. 
> If TLS was taken more seriously, is also LIKELY to endice not 
> just new members.. **but keeping existing ones!**

I couldn't agree more. If the goal is to get users, then the DLF 
has to support what the users want. The DLF needs to decide what 
it's mission is and who it is trying to serve and then do the 
work of understanding the people they are trying to serve. If it 
is themselves, then they don't need to talk to anyone. If they 
are trying to be more popular, then they need to talk to other 
developers and take the time and effort to understand.

Each complaint raised in good faith is coming from someone's 
actual experience. Maybe it's just that they don't understand and 
the documentation needs to be better or more accessible. It's 
also possible that it's an actual problem with the way the 
language is being developed. It's possible they are not in the 
target group. Whatever the case, they have feelings about the 
software and want to be heard. If you hear them, you will learn 
their perspective. It you learn enough perspectives, you will 
know why the language is not popular.

The only fact we can all agree on is the language is not popular 
and that implies that the language designers have not figured out 
why. If they had figured out why, it would be popular or else we 
would mostly just agree conditions were such that it could not be 
popular.

Just about everyone on this forum would be willing to pitch in to 
help the maintainers understand the issues. Those forum users 
need to know how and they need to know they will be listened to 
before they go through the effort again. I am not saying I expect 
this or demand it or anything. I'm just saying if you want to be 
popular or even be a language people have heard of, you will have 
to understand the people who are complaining. If you make it 
their job to be understood, then it is unlikely they will do all 
the work for you.

It might sound like I'm a hater, same as some of the previous 
posters, but HERE I AM trying to make it work again. Here I am 
looking at the D forum, trying to make another go of making this 
my language. I will spare my personal details and just make my 
pitch that I want this language to work but it is hard to justify.


More information about the Digitalmars-d mailing list