www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - State of the release process

reply =?UTF-8?Q?S=C3=B6nke_Ludwig?= <sludwig outerproduct.org> writes:
Over the past two years, the release process seems to have degraded 
considerably and I'm wondering where we currently stand and where we aim 
to be in the future. Some things to consider:

1. Much lower release cadence
2. No point releases anymore
3. In particular, critical macOS blockers not getting sorted by a point 
release
4. No beta releases anymore
5. No release announcement anymore
6. Regressions not receiving the priority they used to
7. New compiler releases introducing a lot more regressions that they 
used to, including in core infrastructure: 
https://github.com/dlang/dub-registry/pull/605

Personally, this feels like the times before we had the Buildkite 
project tester pipeline and every release broke something. I know 
getting the release scripts migrated and sorted has played a big role in 
this and lack of manpower in areas concerning bug fixing may also be an 
issue, but the major part seems to be an issue of project management.

So, the question is, are there plans to work towards getting back to the 
pre-2.110.0 release standards, or is this just the mode of operation to 
be expected?
Jan 12
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 12 January 2026 at 08:59:46 UTC, Sönke Ludwig wrote:


 So, the question is, are there plans to work towards getting 
 back to the pre-2.110.0 release standards, or is this just the 
 mode of operation to be expected?


Dennis can say more, but see here for starters:

https://forum.dlang.org/post/ckfscuzcbkqfqxrdaicg forum.dlang.org
Jan 12
parent reply =?UTF-8?Q?S=C3=B6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 12.01.26 um 13:19 schrieb Mike Parker:

 On Monday, 12 January 2026 at 08:59:46 UTC, Sönke Ludwig wrote:
 

 So, the question is, are there plans to work towards getting back to 
 the pre-2.110.0 release standards, or is this just the mode of 
 operation to be expected?


 
 Dennis can say more, but see here for starters:
 
 https://forum.dlang.org/post/ckfscuzcbkqfqxrdaicg forum.dlang.org


Thanks Mike, I've read this back then. So that means this proposal has 
been accepted and, barring personal reasons, should take effect starting 
with 1.120.0?

IMO, a beta release is still very desirable in order to catch 
regressions or build related issues* early, even if there are not that 
many testers.

* https://github.com/dlang/dmd/issues/21126#issuecomment-3732111601
Jan 12
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On Monday, 12 January 2026 at 13:49:18 UTC, Sönke Ludwig wrote:

 Am 12.01.26 um 13:19 schrieb Mike Parker:

 On Monday, 12 January 2026 at 08:59:46 UTC, Sönke Ludwig wrote:
 

 So, the question is, are there plans to work towards getting 
 back to the pre-2.110.0 release standards, or is this just 
 the mode of operation to be expected?


 
 Dennis can say more, but see here for starters:
 
 https://forum.dlang.org/post/ckfscuzcbkqfqxrdaicg forum.dlang.org


 Thanks Mike, I've read this back then. So that means this 
 proposal has been accepted and, barring personal reasons, 
 should take effect starting with 1.120.0?

 IMO, a beta release is still very desirable in order to catch 
 regressions or build related issues* early, even if there are 
 not that many testers.

 * 
 https://github.com/dlang/dmd/issues/21126#issuecomment-3732111601


FWIW, the macos 15 problem will be resolved soon, and I think 
this is a combination of a lot of changes that are difficult to 
deal with:

1. Sudden change of release manager
2. Very manual process for releases (along with some personal 
infrastructure)
3. Macos test runners can't be upgraded to Macos15 due to 
unrelated issues. This means the auto testing would not catch any 
related segfaults.
4. No native DMD for ARM Mac means tests have to be run on a very 
limited release of systems (only one release supports MacOS15 on 
intel hardware), or run using Rosetta. All GH MacOS runners are 
now ARM.
5. Migration of bug list to github means manual production of 
changelog

I think we are probably going to get back to a more regular 
cadence. I can't speak for Dennis, but I trust he is going to be 
able to solve these issues. I think we will get to a place where 
a release is a button push on github.

The Mac issue has been a huge problem, and I wish we could have 
had a release sooner. I think this has been a perfect storm of 
circumstances to prevent that. I personally have not used DMD for 
years due to quirks in using the compiler via Rosetta that caused 
hard-to-track linker errors. I have at least one user of my 
libraries that has complained about issues related specifically 
to intel MAC running MacOS15. I cannot help him solve this 
without appropriate hardware. I'm hoping 2.112.1 (with the fix 
for the segfault) will help shed some light on the issue.

-Steve
Jan 12
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/12/2026 7:23 AM, Steven Schveighoffer wrote:

 4. No native DMD for ARM Mac means tests have to be run on a very limited 
 release of systems (only one release supports MacOS15 on intel hardware), or
run 
 using Rosetta. All GH MacOS runners are now ARM.


This one is on me.
Jan 12
prev sibling parent reply Dennis <dkorpel gmail.com> writes:
On Monday, 12 January 2026 at 08:59:46 UTC, Sönke Ludwig wrote:

 So, the question is, are there plans to work towards getting 
 back to the pre-2.110.0 release standards, or is this just the 
 mode of operation to be expected?


Not the exact same standards, but definitely better standards 
than last year!


 1. Much lower release cadence


I wanted to lower the cadence a bit, but definitely not down to 
twice a year. The delay is because of technical difficulties.


 2. No point releases anymore
 3. In particular, critical macOS blockers not getting sorted by
 a point release


2.110.0 => 2.111.0 was because at that point, the 2.110 release 
was so delayed that on Discord we agreed to move straight to 
2.111 so long-awaited features could be finally released.
2.111.0 => 2.112.0 was because the old release process with the 
master/stable branch strategy couldn't release a 2.111.1 for the 
MacOS 15.4 fix once 2.112 was initiated (I don't recall the exact 
time frame / circumstance under which 2.112 was initiated).


 4. No beta releases anymore


There are betas, but due to lack of announcements they are easy 
to miss.

https://downloads.dlang.org/pre-releases/2025/


 5. No release announcement anymore


I wanted to announce the 2.112.0 release as soon as it was 
uploaded, but there's 2 blocking issues:

- The dlang.org ddoc pages being stuck on a version from Oct 10 
2025 due to a private Git
extension embedded inside a Git commit object breaking deployment 
(fixed now, thanks to Vladimir Panteleev)
- dmd still segfaulting on MacOS 15.4 because the host LDC 
compiler needs to be updated to include the fix for the related 
issue


 6. Regressions not receiving the priority they used to
 7. New compiler releases introducing a lot more regressions 
 that they used to, including in core infrastructure: 
 https://github.com/dlang/dub-registry/pull/605


Can you provide GitHub issue links for the compiler regressions 
in question?

---

As for the reason of the technical difficulties: As stated in my 
update post last year 
(https://forum.dlang.org/post/ckfscuzcbkqfqxrdaicg forum.dlang.org), I'm
release manager not because I'm qualified, but because nobody else volunteered.
I was given the keys to the kingdom and a script, and hoped that the script
would keep working.

Then the Windows build broke because ImportC suddenly failed to 
compile Visual Studio 2017 headers. At least I have a Windows PC 
on which I could slowly untangle the Windows build and figure out 
how to create a Windows release myself with Visual Studio 2022.

But the MacOS 15.4 issue is in a different league. First of all, 
I'm completely foreign to Apple products. But also: the problem 
is unique because it doesn't just require building a compiler 
with the patch for the fix, but the *host compiler* needs to 
include that fix as well. But upgrading the host LDC from 1.32 to 
1.41 caused the linux build to fail because of missing GLIBC 
versions.

That leaves me where I am now: migrating from the old setup with 
bitrotten Vagrant boxes to more up to date GitHub runners, using 
GitHub actions. I've managed to build a release from the stable 
branch: https://github.com/dlang/dmd/releases/tag/v2.112.1

But branch releases don't include packages (.deb, .rpm, .dmg 
etc.) so I'm trying to build the v2.112.0 tag now, but that's 
causing various failures. For MacOS, the problem is that the 
MakePackage program which the old setup used to create a .dmg is 
deprecated and doesn't exist on the GitHub runners, so 
https://github.com/dlang/installer needs to be updated to use a 
new method. If anyone who actually knows a thing or two about 
MacOS could help out with that, that would be appreciated.
Jan 12
next sibling parent reply M. M. <matus email.cz> writes:
On Monday, 12 January 2026 at 17:20:10 UTC, Dennis wrote:

 On Monday, 12 January 2026 at 08:59:46 UTC, Sönke Ludwig wrote:

 [...]


 Not the exact same standards, but definitely better standards 
 than last year!

 [...]


It's great that you do all this, Dennis, despite you feeling not 
qualified. Would it make sense to get a help from someone like 
"Symmetry of Code"-intern to set-up a new build infrastructure?
Jan 12
parent reply Dennis <dkorpel gmail.com> writes:
On Monday, 12 January 2026 at 21:24:23 UTC, M. M. wrote:

 It's great that you do all this, Dennis, despite you feeling
 not qualified. Would it make sense to get a help from someone
 like "Symmetry of Code"-intern to set-up a new build
 infrastructure?


Razvan suggested this as a Google Summer of Code project 
actually. The problem was that from experience, contestants 
usually have a familiarity with algorithms and popular 
technologies, but not so much the D ecosystem. So it's better to 
have projects that exploit that, letting contestants to build 
something they're familiar with and excited about, but in the 
context of D.

Cleaning up the release process on the other hand requires 
intimate knowledge of all corners of D (dmd, phobos, dub, tools, 
dlang.org, CI, behind the scenes servers maintained by various D 
community members) so it would be very hard to work on without a 
lot of guidance.

That being said, there are several smaller tasks that could 
easily be worked on independently. For example, I don't see why 
we need a [home grown 
concoction](https://github.com/dlang/downloads.dlang.org/blob/mas
er/src/gen_index.d) to generate and index page of some directories on a server.
There's gotta be a simpler off-the-shelf solution for that.

But creating a project, reviewing applications and mentoring also 
take a lot of energy, which could also be spent on tackling the 
problem directly. So it still wouldn't make the burden lighter 
unfortunately. But the good news is, with the new GitHub actions 
workflow going, at least building releases can be done by anyone 
with the right permissions in 1 button click, and it finishes in 
15 minutes. This is a HUGE improvement over the extremely fragile 
and slow Vagrant box setup.
Jan 12
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 13/01/2026 12:41 PM, Dennis wrote:

 That being said, there are several smaller tasks that could easily be 
 worked on independently. For example, I don't see why we need a home 
 grown concoction <https://github.com/dlang/downloads.dlang.org/blob/ 
 master/src/gen_index.d> to generate and index page of some directories 
 on a server. There's gotta be a simpler off-the-shelf solution for that.


That file looks pretty succinct already, I doubt using a prebuilt 
software will lead to less files committed. If anything it adds another 
dependency that you have to get working which would make it harder 
instead of easier.
Jan 12
parent Dennis <dkorpel gmail.com> writes:
On Tuesday, 13 January 2026 at 05:24:55 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 That file looks pretty succinct already, I doubt using a 
 prebuilt software will lead to less files committed. If 
 anything it adds another dependency that you have to get 
 working which would make it harder instead of easier.


Oh you sweet summer child, that file is only the tip of the 
iceberg. Lurking in the depths of the 
[s3_index.d](https://github.com/dlang/downloads.dlang.org/blob/ma
ter/src/s3_index.d) dependency chain are .so linker errors I hacked around to
get it working on only 1 computer. After waiting for its slow completion the
output then needs to transfered to the main build machine to publish it, the
effect of which is only seen once the CDN cache of 2 weeks expires.
Jan 13
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Dennis, I know this is a tough job and really appreciate the work you're doing 
to fix it!
Jan 12
parent Dennis <dkorpel gmail.com> writes:
On Tuesday, 13 January 2026 at 03:02:18 UTC, Walter Bright wrote:

 Dennis, I know this is a tough job and really appreciate the 
 work you're doing to fix it!


<3
Jan 13
prev sibling parent =?UTF-8?Q?S=C3=B6nke_Ludwig?= <sludwig outerproduct.org> writes:
Thanks for mentioning some of the struggles, I can certainly emphasize 
with those, especially with the pain surrounding the macOS ecosystem. 
The latest macOS releases have broken a *lot* of things, not just the 
compiler/runtime issues, and GitHub being eager to get rid of older 
macOS runners definitely doesn't help either.

To be perfectly clear, I highly appreciate your work and none of these 
critical questions were targeted at that!


 4. No beta releases anymore


 
 There are betas, but due to lack of announcements they are easy to miss.
 
 https://downloads.dlang.org/pre-releases/2025/


I think the beta releases should definitely come with a quick D.announce 
post and they should probably also be visible prominently on the website 
in order to attract testers.


 Can you provide GitHub issue links for the compiler regressions in 
 question?


There have been some in the 2.110.0 release and some in 2.111.0, which 
have either been (mostly) resolved by now (e.g. the macOS issues), or I 
have already implemented workarounds on my side (I remember multiple 
issues being related to move constructors, for example). I'd have to to 
some research to dig up the actual issues now, though.

On the good side, I've been able to use DMD for building our main 
project for the first time since many years with 2.112.0, although it 
now triggers an assertion failure at runtime that I still have to look into.

 From my point of view, the important point here is that regressions 
should generally receive the highest priority, ideally as part of the 
public beta phase, or alternatively by triggering an obligatory point 
release.


 (...) For MacOS, the problem is that the MakePackage program which 
 the old setup used to create a .dmg is deprecated and doesn't exist on 
 the GitHub runners, so https://github.com/dlang/installer needs to be 
 updated to use a new method. If anyone who actually knows a thing or two 
 about MacOS could help out with that, that would be appreciated.


Although I know more than I'd like to about macOS by now, I've never 
dealt with .pkg or .dmg. We do have scripts for code signing and 
notarization, but they still require entering a keychain password 
manually, so they won't work on a CI machine.
Jan 15