So D will have LTS or not?

[Martyn]

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!**