State of the release process

[Dennis]

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.