D has become unbearable and it needs to stop

Martyn martyn.developer at googlemail.com
Mon Jun 12 12:12:18 UTC 2023


On Sunday, 11 June 2023 at 23:20:31 UTC, mate wrote:
> On Friday, 9 June 2023 at 07:56:00 UTC, Walter Bright wrote:
>> Thanks for spending the time to post this. We're going to take 
>> it to heart.
>
> Don Clugston also strongly advocated for an LTS:
> https://forum.dlang.org/post/mdjhbyvgxrjmbgzwirja@forum.dlang.org


I am referencing Mike Parkers' comment found inside the above 
link...
https://forum.dlang.org/post/zycmjfzasjmmswtbntim@forum.dlang.org

This is a great example of what I would like to see moving 
forward.

Imagine being able to create a new project and specifying the 
release you would like to use. If you don't have it, it will 
install it for you.

For example, when you `dub init` it could also ask the question 
:- "Which D release would you like? **D23**" etc.

In most cases, users/developers are likely to choose the current 
"milestone" release. However, the previous milestones can also be 
available. For sake of simplicity and point, lets assume the 
current milestone release is D23. Of course, specific releases 
can still be used (ie 2.104.0)

Of course, milestone releases can have patches - but must not 
break things! Ie D23.1 or D23.2, etc.

Imagine the next milestone, D25, being available months and 
months ahead of time as a pre-release (ie D25-Prerelease0.1, etc) 
allowing the maintainers to test/prepare their libraries.


Imagine if D encouraged a rule for libraries to follow to 
specific versioning patterns. For example:- 
{release.major.minor.etc} - Imagine a library having releases 
such as 23.4.2.10 or 25.1.2.0.

This tells us that D23 is available. I have **increased 
confidence** I can download this and "works" inside my D23 
project. There is also a D25 version, the not-yet-released 
milestone. I now have confidence this library is very active into 
the next milestone release.

DUB could also be more intelligent when you `dub add` a 
dependency and, perhaps, handle validation (or test) upgrading to 
the next milestone.

"There is no release for D23. Suggestions...
D25 (25.1.2.0),
D21 (21.4.6.1)"

etc.

Obviously the regular releases can continue...
2.104.0
2.103.0
2.102.0
etc

These all get factored into the next milstone. Imagine a page for 
the next upcomming milestone to contain all of the new/updated 
features -- all on one page.


Yes, I am likely getting carried away with this. I understand 
that some of my points require some (big) changes in various 
areas including DUB - but I am just trying to demonstrate, and 
hopefully well, the many advantages to a LTS system/structure.


Until then, we have regular monthly (or every other month) 
releases. Could the next release break my application? What about 
LibraryX or LibraryY I am using? etc.

Thanks.



More information about the Digitalmars-d mailing list