On Friday, 9 June 2023 at 10:59:35 UTC, Petar Kirov [ZombineDev] wrote:
> 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.
If it were up to me - I'd just split D into D2 and D3. D2 being a stable non-breaking lang that only adds upon what it already has. And D3 being a playground with "whatever goes", until peopel agree it's good enough and split for D4 is required. However, I understand other points of view as well, so having at least some sort of stable release I am willing to treat as "good enough". A two-year cycle is a widely accept practice it seems, so why not adopt it?
> 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 think, in the real world, if you don't add new stuff -- you end up with less bugs, provided you fix existing ones. As in, bug fixes rarely lead to introducing more bugs, it's the development of new features that usually bring new issues. If you localize refactorings to a concrete issue - it's not too difficult to backport everything. Anything else is, unfortunately, tough luck (tm). In my view, an LTS branch should only recieve critical bugfixes, such as compiler crashes or security vulnerabilities. If something leads to a buggy behavior - that's a thing that should be fixed in main branch and released in the next LTS.
> 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.
In my opinion, that is only going to happen if D continues do develop with no clear goal or target. Lack of understanding where D is heading towards is creating that issue almost singlehandedly. Of course you're gonna divert the community if big changes are going to keep popping out of nowhere, like ImportC did. Infact, I think, LTS branch might help bring order to somewhat chaotic nature of D development cycle. Provided that D wants to have any order, which doesn't seem to be the case. Again, it boils down to the fact that D developers (the lang & compiler ones) don't really use D on a day-to-day baiss, outside of the compiler. So they can't even grasp what I and others are talking about. How could they, if their "work" never affects them to any extent, they are free to change and break whatever they want. They don't have to deal with the damages that they cause.
> 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.
It's still the same amount of changes, which are just easier to plan ahead for. And, again, it's not the changes themself that cause me pain, it's how frequent and breaking they are.
> 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.
The whole point of LTS is that everyone has the same version. I have written C++, C#, Obj-C, Java, and many other langs with LTS releases and nobody complained about the "recent" compiler being unsupported. Because everyone understands why it's called an "experimental" version, and they patiently wait for new LTS release.
Permalink
Reply
![Gravatar of Petar Kirov [ZombineDev]](http://www.gravatar.com/avatar/52d6b7597694bbd17fcc28a04ec78954?d=identicon&s=32 "Petar Kirov [ZombineDev]'s Gravatar profile"){kind=small}
![Gravatar of Petar Kirov [ZombineDev]](http://www.gravatar.com/avatar/52d6b7597694bbd17fcc28a04ec78954?d=identicon&s=80 "Petar Kirov [ZombineDev]'s Gravatar profile")
