April 24 Re: DMD release cadence report 2023 | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Iain Buclaw | 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 Re: DMD release cadence report 2023 | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Jonathan M Davis | 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 Re: DMD release cadence report 2023 | ||||
|---|---|---|---|---|
| ||||
Posted in reply to electricface | 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 Re: DMD release cadence report 2023 | ||||
|---|---|---|---|---|
| ||||
Posted in reply to singingbush | 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 Re: DMD release cadence report 2023 | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Iain Buclaw | 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
| |||
Permalink
Reply
