D has become unbearable and it needs to stop

[Petar]

On Friday, 9 June 2023 at 09:22:10 UTC, GrimMaple wrote:
> On Friday, 9 June 2023 at 08:05:18 UTC, Walter Bright wrote:
>> It's not about not caring about it. It's just that I can't see 
>> how it would be effective. Making LTS versions balkanizes the 
>> language into multiple languages, which will play hell with 
>> 3rd party library maintenance.
>
> I disagree with this statement, and I see a lot of people 
> agreeing with my disagreement :)
> LTS is LTS for a reason, meaning that 3rdparty will (ideally) 
> only target LTS, without having to target unpredictable 
> compiler. [..]

What is your vision for LTS releases? How often would a new LTS 
version be released and for how much time would it be supported? 
How many LTS branches would be maintained in parallel? Something 
like the Ubuntu release cycle - 
https://ubuntu.com/about/release-cycle?
What is the range of supported versions that you would expect an 
actively maintained D library to support? Only the oldest LTS, or 
only newest one? What about the current versions?
What are the criteria for backporting changes to an LTS branch? 
While library functionality removals and new compiler errors are 
obviously a no-no, what about deprecations? On one hand, one 
would would prefer things to keep working as they were, but on 
the other hand deprecations are a migration tool - they let the 
users know that they need to adjust their code in order to be 
able to upgrade to a new version down the line.

There's also the question of certain bug fixes: usually druntime 
& phobos are straightforward, but there are some compiler bug 
fixes that can cause surprising regressions that are only 
discovered years (!) later, despite the best effort of everyone. 
I can assure you that this is not a theoretical concern - we've 
had hundreds of regression-causing bug fixes like this. The main 
cause is that the semantic processing part of the compiler 
codebase is very complex and convoluted. While some argue that 
the solution is ground-up from-scratch reimplemtnation (which is 
what the SDC project that has been years in the making is trying 
to accomplish), realistically, the most pragmatic option is to 
continuously refactor the codebase until it becomes much easier 
to maintain and evolve. Which is exactly what almost every major 
compiler contributor has worked towards on many occasions, but 
the reality is that we're still far from the place we want to be, 
and there's much more work to be done.

I don't expect the rate of change to decrease, (and I surely hope 
it doesn't as it means the development is dying!), so I would 
expect the divergence between the LTS release and the current one 
to constantly increase, both in terms of direct user-observable 
language changes, but also in terms of the codebase. There are 
many cases where in order to fix a bug you first need to refactor 
the code (so e.g. the logic is centralized in a single place and 
not spread across multiple files), which would make certain 
commits very difficult to apply to the LTS branch.

And even just in terms of user-facing changes, if the jump from 
LTS to the current release is too big, upgrading would become 
much more time consuming than the current status quo of a major 
release every two months, so in that sense, I would agree with 
Walter that this has the risk of splitting the community.

> I don't understand how this is going to be worse for 3rd party, 
> I only see wins.

While the past few releases may have been heavier on the 
deprecation side of things, once there's a new compiler release 
with shiny new feature X™, you're quite likely to get an influx 
of users requesting support for it, so sticking with an old 
compiler release is unlikely make everyone happy.