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!