April 24

On Monday, 22 April 2024 at 19:56:35 UTC, Iain Buclaw wrote:

>

Hi,

Over the last year, apart from one outlier, have been keeping up with a 2 month major release cadence for DMD, with at least one minor release every off-month.

The following is a rough sketch of the release timeline.

It's fine for me!

Andrea

April 25
On Tuesday, 23 April 2024 at 18:43:31 UTC, Jonathan M Davis wrote:
> On Monday, April 22, 2024 1:56:35 PM MDT Iain Buclaw via Digitalmars-d wrote:
>> Moving forward for the next 12 months, is keeping at this pace fine? Should it slow down or speed up?
>
> I've been fine with the current cadence. I'd also be fine with more frequent major releases. Either way, I wouldn't really want it slowed down. It would get particularly annoying with stuff like additions to the bindings in druntime, since depending on the timing, those can take around two months to become available as things have been, and I wouldn't want to see that take even longer.
>

If there are changes that need to land sooner, then said PRs should target the stable branch which releases are cut from.

I don't have any answers, but if I'm having to explain the process, maybe something is being done wrong. Or maybe it's just there is no one actively thinking about which changes should target which branch when it comes to non-regression fixes.
April 25

On Wednesday, 24 April 2024 at 03:19:54 UTC, electricface wrote:

>

On Monday, 22 April 2024 at 19:56:35 UTC, Iain Buclaw wrote:

>

Hi,

Over the last year, apart from one outlier, have been keeping up with a 2 month major release cadence for DMD, with at least one minor release every off-month.

The following is a rough sketch of the release timeline.

Establish a more sophisticated automated testing system so that we can release versions as quickly as we want.

Yes, eventually I do want to move the entire release script to a CI job. Time is needed and thinking about how best to manage secrets for all the servers involved.

April 25

On Tuesday, 23 April 2024 at 06:33:59 UTC, singingbush wrote:

>

On Monday, 22 April 2024 at 19:56:35 UTC, Iain Buclaw wrote:

>

Should it slow down or speed up?

Iain.

Slow down. There's no need for language changes being so frequent. In fact I see it as a negative. I'd prefer annual releases that are reliable. I've been burned by new releases multiple times and the lack of stability is why I have never been able to use D code for anything significant within the workplace.

By all means keep pushing out regular builds with latest features but I think D should only release a new language version after those changes have been used for a while by people that want to use the latest thing.

My understanding is that - if done right - Editions will disconnect the language changes from the compiler releases, allowing users to go at their own pace whilst still getting all the bug fixes.

April 25
On Wednesday, April 24, 2024 11:51:16 PM MDT Iain Buclaw via Digitalmars-d wrote:
> On Tuesday, 23 April 2024 at 18:43:31 UTC, Jonathan M Davis wrote:
> > On Monday, April 22, 2024 1:56:35 PM MDT Iain Buclaw via
> >
> > Digitalmars-d wrote:
> >> Moving forward for the next 12 months, is keeping at this pace fine? Should it slow down or speed up?
> >
> > I've been fine with the current cadence. I'd also be fine with more frequent major releases. Either way, I wouldn't really want it slowed down. It would get particularly annoying with stuff like additions to the bindings in druntime, since depending on the timing, those can take around two months to become available as things have been, and I wouldn't want to see that take even longer.
>
> If there are changes that need to land sooner, then said PRs should target the stable branch which releases are cut from.
>
> I don't have any answers, but if I'm having to explain the process, maybe something is being done wrong. Or maybe it's just there is no one actively thinking about which changes should target which branch when it comes to non-regression fixes.

It was my understanding that stable was only supposed to have fixes, but I don't know what the exact policy is.

- Jonathan M Davis



May 11
On Thursday, 25 April 2024 at 06:25:02 UTC, Jonathan M Davis wrote:
> On Wednesday, April 24, 2024 11:51:16 PM MDT Iain Buclaw via Digitalmars-d wrote:
>> On Tuesday, 23 April 2024 at 18:43:31 UTC, Jonathan M Davis wrote:
>> > [...]
>>
>> If there are changes that need to land sooner, then said PRs should target the stable branch which releases are cut from.
>>
>> I don't have any answers, but if I'm having to explain the process, maybe something is being done wrong. Or maybe it's just there is no one actively thinking about which changes should target which branch when it comes to non-regression fixes.
>
> It was my understanding that stable was only supposed to have fixes, but I don't know what the exact policy is.
>
> - Jonathan M Davis

Are incomplete or incorrect bindings not fixes?

I'd myself draw the line at accepting new features, refactorings, and breaking changes to the stable branch. But I'm not the arbiter of the branch/repository.
May 11

On Thursday, 25 April 2024 at 05:55:44 UTC, Iain Buclaw wrote:

>

On Wednesday, 24 April 2024 at 03:19:54 UTC, electricface wrote:

>

On Monday, 22 April 2024 at 19:56:35 UTC, Iain Buclaw wrote:

>

Hi,

Over the last year, apart from one outlier, have been keeping up with a 2 month major release cadence for DMD, with at least one minor release every off-month.

The following is a rough sketch of the release timeline.

Establish a more sophisticated automated testing system so that we can release versions as quickly as we want.

Yes, eventually I do want to move the entire release script to a CI job. Time is needed and thinking about how best to manage secrets for all the servers involved.

thanks for sharing

May 19

On Monday, 22 April 2024 at 19:56:35 UTC, Iain Buclaw wrote:

>

Moving forward for the next 12 months, is keeping at this pace fine? Should it slow down or speed up?

The current cadence has helped me more than once this past year, through corresponding releases of ldc and their distribution in Debian Testing and Unstable. Because of this, bug fixes and language additions made their way to me within a useful time frame, rather than months or years too late to be helpful.

(I understand that some people prefer to get the compiler through a more direct channel, but that doesn't fit my needs. D's availability in the Debian archive is a significant factor in my choosing it over other languages.)

So, speaking selfishly, I wouldn't like releases to slow down much, if at all.

1 2
Next ›   Last »