On Thursday, 1 October 2020 at 09:49:20 UTC, WB wrote:
> Having a LTS version does literally nothing to make this happen. To make this work, an engineer has to be available to make it work, someone that can "add patch X to release Y". The only way that can happen is for someone to volunteer to do it, or for someone to be paid to do it.

When a pull request is made, it would be trivial to require a patch to also be made to a LTS version of the compiler.

> Another problem is there are what, 20,000 PRs for dmd? Which ones need to be put in the LTS version? Who decides? The only workable scheme I can think of is the customer who needs X (every customer has different issues that need attention) needs to find or fund an engineer to do it. This is why D is open source.

Who decides now?

The people deciding now have no recourse, the current `-preview=` implementation only works if the before and after code can co-exist. Which in a lot of cases it can't. Not to mention there's no `-preview=` switch for breaking changes done to phobos. It's an ineffective tool for the problem.

See here: https://github.com/dlang/dmd/pull/9289#issuecomment-468633169

    "" It seems that the projects listed in buildkite don't suffer from this bug so I suggest we just swallow this pill and merge this. ""

Had an LTS version, or some sort of spec versioning scheme been used, this situation could have allowed the people deciding to only apply this patch to be applied to the new spec or not the LTS version of the compiler.

Of course it ended up causing problems: https://forum.dlang.org/post/zzgbrxtehffhjkcazpzs@forum.dlang.org

Every company and/or customer requires LTS. It is ubiquitous. There's no customer Y needs X, that's just a symptom of a larger problem. Customer Y needs X cause there's no LTS.

> All I can helpfully suggest is we (the topic of this thread) avoid removing harmless features just because they are obsolete. This will reduce (hopefully eliminate) the redesigns necessary to move forward.

I think this will only exacerbate the problem, if you mean to suggest to follow through with "ghosting" features. If what is said to be taken at face value, since all bug reports for that feature will be closed as "won't fix". Should a regression occur to a ghosted feature, it won't ever be fixed. So even if a "ghosted" feature remains it will still cause problems for someone trying to upgrade to a newer version of the compiler. A ghosted feature can't remain without support for it, otherwise it might as well be removed.