www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - =?UTF-8?B?V2hhdOKAmXM=?= up with v2.110?

reply Quirin Schroll <qs.il.paperinik gmail.com> writes:
I don’t want to be that guy again, but v2.110 was supposed to be 
released Feb. 1, so is it Ian not being available still?
Feb 17
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, February 17, 2025 6:13:17 AM MST Quirin Schroll via Digitalmars-d
wrote:

 I don’t want to be that guy again, but v2.110 was supposed to be
 released Feb. 1, so is it Ian not being available still?


He did finally get to working on the release, but the switch from bugzilla
to github issues got in the way, because the script that generates the
changelog no longer worked properly, and the initial attempt to fix it
included all of the PRs from github in addition to the issues rather than
just the fixed issues. So, that needs to be sorted out, and I'm not sure
where that currently stands at present, but it was brought up in the DLF
meeting earlier this month, and Robert is aware of what needs to be done.
So, it'll probably happen soon, but I don't know when exactly.

I also don't know if that's the only issue remaining which blocks the
release or not, but there is a DMD Beta 2.110.0-rc.1 available for download
on dlang.org.

- Jonathan M Davis
Feb 17
prev sibling parent reply FeepingCreature <feepingcreature gmail.com> writes:
I don't want to push on Ian but at what point does this start to 
become an existential issue? Like at what point do you say "okay 
we're not getting a release page this time but we're tagging it 
anyway?" It's been the better part of a *year.* The project 
already doesn't have too many contributors, and at some point the 
question will be raised "well, we've been writing bugfixes, so 
are we going to see them in a release soon?"

My recommendation would be to commit to a date. I mean, aside 
from February 1st, idk, some time in March, first of April at the 
latest. If the tooling isn't there at that point, put a release 
up manually, say "this script doesn't work right now" in the 
changelog. The project isn't viable if it can't release.
Mar 03
next sibling parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Monday, 3 March 2025 at 09:22:25 UTC, FeepingCreature wrote:

 I don't want to push on Ian but at what point does this start 
 to become an existential issue? Like at what point do you say 
 "okay we're not getting a release page this time but we're 
 tagging it anyway?" It's been the better part of a *year.* The 
 project already doesn't have too many contributors, and at some 
 point the question will be raised "well, we've been writing 
 bugfixes, so are we going to see them in a release soon?"

 My recommendation would be to commit to a date. I mean, aside 
 from February 1st, idk, some time in March, first of April at 
 the latest. If the tooling isn't there at that point, put a 
 release up manually, say "this script doesn't work right now" 
 in the changelog. The project isn't viable if it can't release.


I did some analysis: https://i.imgur.com/13CSAlk.png

 From the markings, you can pretty clearly see my theory, but you 
can also see that I don't know what I'm talking about and there 
doesn't actually seem to be any clear correlation between release 
and post activity. And I suspect this data is dominated by 
contentious megathreads - though, no release, nothing to talk 
about seems to hold, though with some delay.
Mar 03
parent reply Sergey <kornburn yandex.ru> writes:
On Monday, 3 March 2025 at 10:18:13 UTC, FeepingCreature wrote:

 no release, nothing to talk about seems to hold, though with 
 some delay.


I know that I'm in a minority, but personally I find it is a bad 
indicator.
 From my perspective - too much attention on compiler itself and 
other internal stuff, rather than things done with the language 
as a tool.

There are so many things that can be discussed:
- tooling implemented for D
- games and game engines developed in D
- business and web applications developed with D
- new libraries and algorithms
- etc etc

See how many things don't care at all about new releases? but 
those discussions are quite rare..
And this is what should be improved in my opinion, not new fancy 
features or how bad `cast(ref T)`
Mar 03
parent f <f abc.com> writes:
 I know that I'm in a minority, but - tooling implemented for D


+1


 - business and web applications developed with D


+10


 - new libraries and algorithms


+20
Mar 03
prev sibling next sibling parent reply Vindex9 <tech.vindex gmail.com> writes:
On Monday, 3 March 2025 at 09:22:25 UTC, FeepingCreature wrote:

 If the tooling isn't there at that point, put a release up 
 manually, say "this script doesn't work right now" in the 
 changelog. The project isn't viable if it can't release.


Totally agree. For some reason it's no problem for ldc2 to make a 
release tied to the unreleased dmd 2.110. Nothing will change for 
me, I love D, a lot of my projects are tied to it, but in general 
such delays are scary and can have a bad effect on the community.
Mar 04
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 04/03/2025 9:57 PM, Vindex9 wrote:

 On Monday, 3 March 2025 at 09:22:25 UTC, FeepingCreature wrote:

 If the tooling isn't there at that point, put a release up manually, 
 say "this script doesn't work right now" in the changelog. The project 
 isn't viable if it can't release.


 
 Totally agree. For some reason it's no problem for ldc2 to make a 
 release tied to the unreleased dmd 2.110. Nothing will change for me, I 
 love D, a lot of my projects are tied to it, but in general such delays 
 are scary and can have a bad effect on the community.


Ldc doesn't have to deal with changelog like dmd does, and has its 
releases automated as part of CI.

They are not setup the same unfortunately.

Hopefully Iain can fix the release process to be CI based once the 
changelog stuff has been sorted out.
Mar 04
prev sibling parent reply Adam Wilson <flyboynw gmail.com> writes:
On Monday, 3 March 2025 at 09:22:25 UTC, FeepingCreature wrote:

 I don't want to push on Ian but at what point does this start 
 to become an existential issue? Like at what point do you say 
 "okay we're not getting a release page this time but we're 
 tagging it anyway?" It's been the better part of a *year.* The 
 project already doesn't have too many contributors, and at some 
 point the question will be raised "well, we've been writing 
 bugfixes, so are we going to see them in a release soon?"


Honestly, I barely noticed. 109 has been a solid release and I 
used it until the last BeerConf when I needed the nightlies to 
get an ImportC fix I had requested the day before.

Which, in my opinion, is exactly what you should be doing if you 
need a bug-fix. If you need a bug-fix that quickly than even the 
monthly cadence is too long to wait, so you would be best served 
by using a nightly. This also shortens the loop on any further 
fixes you might need and you'll catch regressions long before 
they make it into the next release, and then you have to wait for 
the release after that to get them fixed, so you could easily end 
up burning two months waiting.

If you need the bleeding edge, you need the nightlies, a 
fast-rolling release cadence is a poor substitute.


 The project isn't viable if it can't release.


Nobody says this about other languages despite them being on much 
longer release timelines. C++ is three years. Rust editions are 


In the grand scheme of things a yearly release cadence is 
actually pretty quick.

Now that I think about it, we follow the SemVer formatting, but 
we don't actually follow SemVer. That might be something worth 
looking into.
Mar 04
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Tuesday, 4 March 2025 at 23:08:37 UTC, Adam Wilson wrote:

 On Monday, 3 March 2025 at 09:22:25 UTC, FeepingCreature wrote:

 The project isn't viable if it can't release.


 Nobody says this about other languages despite them being on 
 much longer release timelines. C++ is three years. Rust 


 In the grand scheme of things a yearly release cadence is 
 actually pretty quick.


Nobody would be worried if we were switching to a yearly release 
cadence on purpose. What worries people is that we've set targets 
for the release of 2.110.0 and missed them, repeatedly, without 
intending to.

If a project repeatedly fails to achieve the goals it sets for 
itself, that does not generally bode well for the project's 
future.
Mar 04
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 5 March 2025 at 01:45:32 UTC, Paul Backus wrote:


 If a project repeatedly fails to achieve the goals it sets for 
 itself, that does not generally bode well for the project's 
 future.


This is a consequence of having a complex release process that's 
dependent on one person, and not a reflection on anything beyond 
that. In hindsight, it's surprising that it hasn't happened 
before now.

The upside is that it's highlighted the necessity to simplify and 
de-bottleneck the release process so that when the primary is 
unavailable, someone else can handle it.
Mar 04
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Wednesday, 5 March 2025 at 03:38:27 UTC, Mike Parker wrote:

 On Wednesday, 5 March 2025 at 01:45:32 UTC, Paul Backus wrote:

 This is a consequence of having a complex release process 
 that's dependent on one person, and not a reflection on 
 anything beyond that. In hindsight, it's surprising that it 
 hasn't happened before now.


And for the record, a release candidate has been available for 
download for a few weeks. The holdup, as Johnathan mentioned, was 
an issue with the changelog resulting from the Bugzilla to GitHub 
migration. Robert recently updated the PR to fix it, and Iain 
left some review comments yesterday:

https://github.com/dlang/tools/pull/466
Mar 04
prev sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Wednesday, 5 March 2025 at 03:38:27 UTC, Mike Parker wrote:

 On Wednesday, 5 March 2025 at 01:45:32 UTC, Paul Backus wrote:


 If a project repeatedly fails to achieve the goals it sets for 
 itself, that does not generally bode well for the project's 
 future.


 This is a consequence of having a complex release process 
 that's dependent on one person, and not a reflection on 
 anything beyond that. In hindsight, it's surprising that it 
 hasn't happened before now.

 The upside is that it's highlighted the necessity to simplify 
 and de-bottleneck the release process so that when the primary 
 is unavailable, someone else can handle it.


I bet adr could make a binary whenever you want. V2.110++ would 
be a fantastic release
Mar 04
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 05/03/2025 6:18 PM, monkyyy wrote:

 On Wednesday, 5 March 2025 at 03:38:27 UTC, Mike Parker wrote:

 On Wednesday, 5 March 2025 at 01:45:32 UTC, Paul Backus wrote:


 If a project repeatedly fails to achieve the goals it sets for 
 itself, that does not generally bode well for the project's future.


 This is a consequence of having a complex release process that's 
 dependent on one person, and not a reflection on anything beyond that. 
 In hindsight, it's surprising that it hasn't happened before now.

 The upside is that it's highlighted the necessity to simplify and de- 
 bottleneck the release process so that when the primary is 
 unavailable, someone else can handle it.


 
 I bet adr could make a binary whenever you want. V2.110++ would be a 
 fantastic release


The nightlies are almost identical to the release binaries, they are in 
no way shape or form what is limiting it.

There is a lot more to the release _process_ than just making a binary.

I.e. change log handling, which is held up by the migration to GitHub 
issues.
Mar 04
prev sibling parent reply Adam Wilson <flyboynw gmail.com> writes:
On Wednesday, 5 March 2025 at 01:45:32 UTC, Paul Backus wrote:

 Nobody would be worried if we were switching to a yearly 
 release cadence on purpose. What worries people is that we've 
 set targets for the release of 2.110.0 and missed them, 
 repeatedly, without intending to.

 If a project repeatedly fails to achieve the goals it sets for 
 itself, that does not generally bode well for the project's 
 future.


It may be a bit anecdotal but we don't seem to have suffered for 
it. While NG traffic may be down, the Discord has been picking up 
quite a few new faces recently and text-traffic in there is as 
high as it's ever been. YMMV and all. 🤷‍♂️

IMO, the fact that it hasn't been a major problem would suggest 
that our current cadence might be a bit too intense. And a slower 
cadence would reduce updating/maintenance work for those of us 
who run build-farms.
Mar 05
parent reply matheus <matheus gmail.com> writes:
On Wednesday, 5 March 2025 at 09:15:20 UTC, Adam Wilson wrote:

 ...
 It may be a bit anecdotal but we don't seem to have suffered 
 for it. While NG traffic may be down, the Discord has been 
 picking up quite a few new faces recently and text-traffic in 
 there is as high as it's ever been. YMMV and all. 🤷‍♂️
 ...


I don't understand why not using the NG as a main medium. Relying 
on other social tool my be mistake, information may be lost and 
people need to sign up to most of those "free services".

This NG is so easy to talk and pretty much is all easily archived 
by default.

I think this fragmentation of communication is not good.

You should ask them to come here.

Matheus.
Mar 07
next sibling parent Adam Wilson <flyboynw gmail.com> writes:
On Friday, 7 March 2025 at 11:16:45 UTC, matheus wrote:

 I don't understand why not using the NG as a main medium. 
 Relying on other social tool my be mistake, information may be 
 lost and people need to sign up to most of those "free 
 services".

 This NG is so easy to talk and pretty much is all easily 
 archived by default.

 I think this fragmentation of communication is not good.

 You should ask them to come here.

 Matheus.


Because Discord is where the bulk of the discussion happens? 
That's just the way things are, and we can't demand that people 
use the medium that we want them to. We have to go where they are.
Mar 11
prev sibling parent reply Sergey <kornburn yandex.ru> writes:
On Friday, 7 March 2025 at 11:16:45 UTC, matheus wrote:

 This NG is so easy to talk and pretty much is all easily 
 archived by default.


and doesn't support many things which we have in Discord.
And the Discord now is de facto standard. Many tech projects have 
their discord servers to handle community..


 I think this fragmentation of communication is not good.


Many people are reading both..


 You should ask them to come here.


Most probably it is not gonna happen..
We had a poll there


 To interact with D community (asking/answering questions) I:
 prefer to use only Discord - 13 (59%)
 prefer to use only Forum - 1 (5%)
 prefer to use both Discord and Forum - 8 (36%)
Mar 11
parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Tuesday, 11 March 2025 at 22:14:16 UTC, Sergey wrote:

 On Friday, 7 March 2025 at 11:16:45 UTC, matheus wrote:

 This NG is so easy to talk and pretty much is all easily 
 archived by default.


 and doesn't support many things which we have in Discord.
 And the Discord now is de facto standard. Many tech projects 
 have their discord servers to handle community..


you can just say everyone is wrong; lets all practice, repeat 
after me

"Discord is a bad standard"
Mar 12
parent reply Sergey <kornburn yandex.ru> writes:
On Wednesday, 12 March 2025 at 08:21:01 UTC, monkyyy wrote:

 On Tuesday, 11 March 2025 at 22:14:16 UTC, Sergey wrote:

 On Friday, 7 March 2025 at 11:16:45 UTC, matheus wrote:


 "Discord is a bad standard"


Any technical reasons?
Because "Discord" is also convenient, because used not only for D 
channel, but for other cool project channels..
Mar 12
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, March 12, 2025 3:45:15 AM MDT Sergey via Digitalmars-d wrote:

 On Wednesday, 12 March 2025 at 08:21:01 UTC, monkyyy wrote:

 On Tuesday, 11 March 2025 at 22:14:16 UTC, Sergey wrote:

 On Friday, 7 March 2025 at 11:16:45 UTC, matheus wrote:


 "Discord is a bad standard"


 Any technical reasons?
 Because "Discord" is also convenient, because used not only for D
 channel, but for other cool project channels..


Discord is basically a chat application. Chat applications work well for
fast, temporary communication. They're terrible for anything that you want
to stick around and be read or searched for later. They're also generally
terrible at anything that involves threading. You're basically getting one
stream of messages back and forth rather than a more organized, threaded
discussion of responses.

The newsgroup / forum / mailing list does a much better job of providing
something that actually sticks around and can be searched through. It also
has threading so that discussions can be broken up into replies to specific
posts rather than smashing everything into a single stream of messages back
and forth. The newsgroup also works better when longer replies are needed.

The main downside over discord (or any form of chat application) is that
there's a much larger delay between responses. If you're looking for a quick
response, and folks are paying attention to discord, you might get a
response pretty quickly, but the newsgroup / forum / mailing is not set up
in a way that really makes it easy to see immediately when a message shows
up - and the technology being used inherently adds delay into the process as
the messages are propagated to the newsgroup from the forum or mailing list
"wrappers" around the newsgroup - and then back from the newsgroup to those
"wrappers" to see the message through whatever UI endpoint the user has
chosen to use (meaning that a fast message generally takes a few minutes to
propagate). And maybe it's that delay that causes some folks to prefer
discord - or maybe it's just something about how some of the younger folks
think and operate that I don't understand (not that I'm old, but I'm not
twenty-something anymore, and clearly, there's been a change in how some of
the younger folks deal with communication online as social media has grown).

Ultimately, whatever the pros and cons, we're kind of stuck having more than
just the newsgroup / forum / mailing list as a major point of communication,
because lots of folks just don't like posting here for whatever reason, and
some of those folks are willing to use discord. But there's clearly a real
cost to it, because it means that all of that stuff that gets discussed on
discord is lost. It just doesn't work to search through discord messages to
find much, and no matter how good or bad discord's search is, you're not
going to get those messages when you search with a search engine like
Google. On the other hand, the messages from the newsgroup _do_ end up in
such searches. So, instead of someone searching for an answer to a question
and finding it on the newsgroup, increasingly, they won't find anything,
because the question was asked on discord - and will probably be asked again
and again on discord, because the answer effectively went into a blackhole
each time. The person who asked it got their answer, but the next person who
comes along with a similar question won't see that answer. With the
newsgroup, it's not hard to find posts from 10 or 15 years ago, but if that
communication had happened through discord, you'd have a hard time finding
it if it had happened last week.

It's kind of like the difference between a phone call and an e-mail. Discord
messages don't get the added benefit that comes from hearing someone's tone,
and the messages stick around a bit longer than someone's voice, but like a
conversation over the phone, discord messages are quick and effectively gone
once said, whereas e-mail is slower, but it sticks around where it can be
searched through and reread later.

Discord makes sense for when you've got some buddies shooting the breeze,
but it's clearly inferior for technical discussions, because it's designed
to be transitory. If that's what folks insist on using, then we need to
accommodate that on some level if we want that communication to be taking
place, but I don't see how there's any argument that it's better from a
technical perspective aside from the fact that the communication is
typically much faster.

- Jonathan M Davis
Mar 13
parent Sergey <kornburn yandex.ru> writes:
On Thursday, 13 March 2025 at 21:50:50 UTC, Jonathan M Davis 
wrote:

 On Wednesday, March 12, 2025 3:45:15 AM MDT Sergey via 
 Digitalmars-d wrote:
 Discord makes sense for when you've got some buddies shooting 
 the breeze, but it's clearly inferior for technical 
 discussions, because it's designed to be transitory. If that's 
 what folks insist on using, then we need to accommodate that on 
 some level if we want that communication to be taking place, 
 but I don't see how there's any argument that it's better from 
 a technical perspective aside from the fact that the 
 communication is typically much faster.

 - Jonathan M Davis


It really depends on how to use the platform.
I agree that it is mostly for chatting, but there are topics. And 
topics are mostly what "threads" in Forum are. So they are 
separate places for specific discussions.

Another thing - there are some tools for chat exporting. So it 
will be possible to get the whole data.. and feed it to LLM for 
better search maybe.

Also there are an APIs available and it is possible to write a 
bot that can even save short question-answer conversations and 
post them on the Forum..

So there are many possibilities, but they are just not used 
currently..
Mar 13
prev sibling parent reply Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Tuesday, 4 March 2025 at 23:08:37 UTC, Adam Wilson wrote:

 The project isn't viable if it can't release.


 Nobody says this about other languages despite them being on 
 much longer release timelines. C++ is three years. Rust 



That is *language* version schedules, not *compiler* version 
schedules. There are updates to MSVC around every few months.


 In the grand scheme of things a yearly release cadence is 
 actually pretty quick.


For languages, yes. For compilers, no.
Mar 05
parent Adam Wilson <flyboynw gmail.com> writes:
On Thursday, 6 March 2025 at 00:08:00 UTC, Quirin Schroll wrote:

 On Tuesday, 4 March 2025 at 23:08:37 UTC, Adam Wilson wrote:

 The project isn't viable if it can't release.


 Nobody says this about other languages despite them being on 
 much longer release timelines. C++ is three years. Rust 



 That is *language* version schedules, not *compiler* version 
 schedules. There are updates to MSVC around every few months.


 In the grand scheme of things a yearly release cadence is 
 actually pretty quick.


 For languages, yes. For compilers, no.


But that's exactly what I am talking about. MSVC gets 
regression/critical fixes monthly, standard bug fixes and 
features every 3 months, and ISO Standard upgrades every three 
years.

What I suggested isn't materially different. With the caveat that 
we're not an ISO standard so we get to choose our language 
feature release cadence.

We can do monthly point release for ice/regressions/critical 
fixes and then say 6 months for  features and standard bug fixes.
Mar 06