digitalmars.D - DMD release cadence report 2023
- Iain Buclaw (79/79) Apr 22 Hi,
- Richard (Rikki) Andrew Cattermole (5/14) Apr 22 The releases lately have felt far too small.
- Lance Bachmeier (7/21) Apr 22 I'm not opposed to using the nightlies if Walter's just
- zjh (4/11) Apr 22 I personally hope to be `faster` and be able to use the latest
- singingbush (16/18) Apr 22 Slow down. There's no need for language changes being so
- Iain Buclaw (5/19) Apr 24 My understanding is that - if done right - Editions will
- jmh530 (8/13) Apr 23 It's one of those things where if there are bug fixes or new
- Guillaume Piolat (2/9) Apr 23 +1
- Jonathan M Davis (8/10) Apr 23 I've been fine with the current cadence. I'd also be fine with more freq...
- Iain Buclaw (7/18) Apr 24 If there are changes that need to land sooner, then said PRs
- Jonathan M Davis (5/25) Apr 24 It was my understanding that stable was only supposed to have fixes, but...
- Iain Buclaw (6/23) May 11 Are incomplete or incorrect bindings not fixes?
- Sergey (22/25) Apr 23 As a hobby user of D - personally not really care..
- electricface (3/8) Apr 23 Establish a more sophisticated automated testing system so that
- Iain Buclaw (4/14) Apr 24 Yes, eventually I do want to move the entire release script to a
- moisee (2/17) May 11 thanks for sharing
- Andrea Fontana (3/9) Apr 24 It's fine for me!
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.
```
... former releases ...
|
+-- DMD 2.103.x stable ------+
| \
DMD 2.104.x development \
| (2023-03-01) v
| DMD 2.103.0 release (2023-04-01)
| \
| v
| DMD 2.103.1 release (2023-05-01)
|
+-- DMD 2.104.x stable ------+
| \
DMD 2.105.x development \
| (2023-05-01) v
| DMD 2.104.0 release (2023-06-01)
| \
| v
| DMD 2.104.1 release (2023-07-01)
| \
| v
| DMD 2.104.2 release (2023-07-15)
|
+-- DMD 2.105.x stable ------+
| \
DMD 2.106.x development \
| (2023-07-15) v
| DMD 2.105.0 release (2023-08-01)
| \
| v
| DMD 2.105.1 release (2023-09-01)
| \
| v
| DMD 2.105.2 release (2023-09-15)
| \
| v
| DMD 2.105.3 release (2023-11-01)
|
+-- DMD 2.106.x stable ------+
| \
DMD 2.107.x development \
| (2023-11-01) v
| DMD 2.106.0 release (2023-12-01)
| \
| v
| DMD 2.106.1 release (2024-01-01)
|
+-- DMD 2.107.x stable ------+
| \
DMD 2.108.x development \
| (2024-01-01) v
| DMD 2.107.0 release (2024-02-01)
| \
| v
| DMD 2.107.1 release (2024-03-01)
|
+-- DMD 2.108.x stable ------+
| \
DMD 2.109.x development \
| (2024-03-01) v
| DMD 2.108.0 release (2024-04-01)
|
v
```
Including the beta and release candidates, this adds up to around
30 releases in the last year:
- 5 beta
- 13 release candidates
- 5 major
- 8 point releases.
Moving forward for the next 12 months, is keeping at this pace
fine? Should it slow down or speed up?
Iain.
Apr 22
On 23/04/2024 7:56 AM, Iain Buclaw wrote:Including the beta and release candidates, this adds up to around 30 releases in the last year: - 5 beta - 13 release candidates - 5 major - 8 point releases. Moving forward for the next 12 months, is keeping at this pace fine? Should it slow down or speed up?The releases lately have felt far too small. I'd rather we slowed down, did more point releases and get into the habit of using the nightlies (which may not be compiled with ldc currently but should be).
Apr 22
Lance Bachmeier <no spam.net> On Monday, 22 April 2024 at 20:14:34 UTC, Richard (Rikki) Andrew Cattermole wrote:On 23/04/2024 7:56 AM, Iain Buclaw wrote:I'm not opposed to using the nightlies if Walter's just implemented new functionality in the compiler. That said, I'd much rather have more release candidates if we're going to cut back on releases. One reason is the difficulty of getting help for a nightly release.Including the beta and release candidates, this adds up to around 30 releases in the last year: - 5 beta - 13 release candidates - 5 major - 8 point releases. Moving forward for the next 12 months, is keeping at this pace fine? Should it slow down or speed up?The releases lately have felt far too small. I'd rather we slowed down, did more point releases and get into the habit of using the nightlies (which may not be compiled with ldc currently but should be).
Apr 22
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. Moving forward for the next 12 months, is keeping at this pace fine? Should it slow down or speed up? Iain.I personally hope to be `faster` and be able to use the latest version immediately, even with a small release `every week`. I can use the `latest version` directly.
Apr 22
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. Also worth pointing out that language changes effect anyone working on D tooling, IDE integration, or libraries/frameworks. I'd be happier with frequent releases if all changes were supported from day 1 but that's unlikely to ever happen. Things would be better if D releases were put out at the same time as a fully compatible language server and grammar file.
Apr 22
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: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.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.
Apr 24
On Monday, 22 April 2024 at 19:56:35 UTC, Iain Buclaw wrote:Hi, [snip] Moving forward for the next 12 months, is keeping at this pace fine? Should it slow down or speed up? Iain.It's one of those things where if there are bug fixes or new features I want to use, then the new release can't come soon enough, but otherwise I don't think about it that much. I would largely defer to the people who actually do the hard work of handling the releases (like yourself). I don't know how much of a burden it is so I don't feel comfortable telling you to speed it up or that we shouldn't slow it down.
Apr 23
On Tuesday, 23 April 2024 at 12:21:04 UTC, jmh530 wrote:It's one of those things where if there are bug fixes or new features I want to use, then the new release can't come soon enough, but otherwise I don't think about it that much. I would largely defer to the people who actually do the hard work of handling the releases (like yourself). I don't know how much of a burden it is so I don't feel comfortable telling you to speed it up or that we shouldn't slow it down.+1
Apr 23
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. - Jonathan M Davis
Apr 23
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: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.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.
Apr 24
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:It was my understanding that stable was only supposed to have fixes, but I don't know what the exact policy is. - Jonathan M DavisOn Monday, April 22, 2024 1:56:35 PM MDT Iain Buclaw via Digitalmars-d 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.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.
Apr 24
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: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.On Tuesday, 23 April 2024 at 18:43:31 UTC, Jonathan M Davis wrote: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[...]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.
May 11
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? Iain.As a hobby user of D - personally not really care.. But just to share my idea, how it could be improved: The speed itself probably not that important. Predictability would be much more desired. By predictability I mean - in the beginning of the cycle (start of the year) Core team is choosing things that they wanted to implement/fix (high level estimation). And again only the order of those things is important, not actual dates. Something like: In this year we would like to: * Add string interpolation * Add tuples * Add pattern matching (with fix of sumtypes) * Implement modern concurrency (with fix of allocators) So community and especially tooling people will be able to plan their work for tools support as well. Of course fixing some bugs is a continuous infinite task. This approach could eliminate situations like "nobody asking but hey now you have to live with this cool feature! It is easy PR - ready to merge", which is after several years still not ready..
Apr 23
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.
Apr 23
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: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.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.
Apr 24
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:thanks for sharingOn Monday, 22 April 2024 at 19:56:35 UTC, Iain Buclaw wrote: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.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.
May 11
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
Apr 24