I don't have time to write a proper post, but I have a suggestion.

Could we increase the time between releases?

Today we have in practice 15 days between minor versions. That might be ok, but "major" releases are too frequent.

The logic behind that is it would hopefully put more focus on testing and reliability etc. If we have to live with a release for a longer time period, the theory is everyone will be more cautious when making a change.

Theory vs practice applies ofc, but I think it could be positive. As for what amount of time makes most sense, I'm not sure yet.

Thoughts?

On Wednesday, 3 November 2021 at 09:13:59 UTC, Imperatorn wrote:

I think your hopes here are probably misplaced. Every change to D's core components (dmd, druntime, and phobos) is already run through the full CI suite and subject to code review before merging. The kinds of bugs that slip past these filters are probably not going to be caught by something as simple as "more caution."

On Wednesday, 3 November 2021 at 14:30:52 UTC, Paul Backus wrote:

I'm not thinking primarily about the code itself, but rather the overall structure and support/maintainability.

On Wednesday, 3 November 2021 at 09:13:59 UTC, Imperatorn wrote:

My preference is once a year, after dconf, they release a new stable version of the compiler. That wouldn't prevent them from having other releases in between, they just wouldn't be "stable" releases. I don't think this will go anywhere though. It's been discussed before and most people don't see a need to change it.

On Wednesday, 3 November 2021 at 14:30:52 UTC, Paul Backus wrote:

Worse: they'll take longer to be be discovered and fixed.

On Wednesday, 3 November 2021 at 15:35:51 UTC, bachmeier wrote:

Yeah, there's no such thing as a new idea. I just wasn't around when those discussions where had 😎

I think we have pretty good tests for our code, so I'm not so scared there. It's more what you could maybe call "architectural hygiene", how you plan for changes, what to do when requirement x comes up, should we use strict semver etc.

On Wednesday, 3 November 2021 at 15:36:41 UTC, deadalnix wrote:

What's the alternative? Just rolling releases every day or even don't have releases at all?

To me a release is something that signifies a unit of some kind, stuff that belongs together.

On Wednesday, 3 November 2021 at 09:13:59 UTC, Imperatorn wrote:

From 2012 to 2014 there was about 3 releases of DMD per year and everyone cheered up when the pace of releases went faster again. It's not sure you would like slower releases too much.

On Wednesday, 3 November 2021 at 16:59:26 UTC, Guillaume Piolat wrote:

I understand. But wouldn't that depend on the quality of the releases?

On Wednesday, 3 November 2021 at 16:09:27 UTC, Imperatorn wrote:

The two main advantages from my perspective:

• It's easy to follow and plan for changes if the release is once a year. I am not an insider, so it is difficult to keep track of everything. I usually learn about changes because I installed a new version of the compiler and I'm getting warnings or error messages.
• You can add a preview flag for a potential feature to the frequent releases but never add it to the stable release if it doesn't show its worth.

A good example of how this hurts from a marketing perspective: most non-users are unlikely to ever hear of importC. It showed up in a random release alongside bug fixes. If you had a single presentation each year showing off all the things coming in the next "release" you could generate some buzz.