There have been 6 major releases of dmd over the last year, with ldc trying to keep pace, currently only one release behind. This is a big jump up from the previous release schedule, I see 2 major releases in 2014, 3 in 2015, and 3 in 2016.

There are obviously pros and cons to each pace, and this has been debated internally before, with one of the ldc devs again posting to the Internals mailing list today questioning the current speed.

I thought I'd open it up to the community: now that you've experienced this faster pace, as a user of the D compilers, how do you like it? Would you prefer a slower release schedule, say 3-4 major releases a year?

I thought 6/year was an ambitious schedule when announced and I wonder if it isn't putting too much strain on our few release maintainers, maybe 3-4 releases/year would be a more gradual bump up.

On Monday, 14 May 2018 at 07:20:48 UTC, Joakim wrote:

> There are obviously pros and cons to each pace, and this has been debated internally before, with one of the ldc devs again posting to the Internals mailing list today questioning the current speed.

The post is here: https://forum.dlang.org/post/ingkexhebiaqdzknicvr@forum.dlang.org

My interpretation of that post is it's not the frequency of releases that's the problem, but rather that bug fixes and language changes are mixed together in each release.  If it's really a problem, one potential solution could be to keep bug fix releases every 2 months, but only release language changes every 4 or 6 months.  But that's not cost-free either, as it will put more of a burden on compiler developers and release managers to maintain parallel branches and deal with the inevitable hassle and controversy involved in deciding which PR goes in which branch, as sometimes bug fixes and language changes are the same thing.  Reviewing PRs requires quite a bit of subjective judgement and conflicting opinions, and it's best to not add more aggravation to an already aggravating process.

> I thought I'd open it up to the community: now that you've experienced this faster pace, as a user of the D compilers, how do you like it? Would you prefer a slower release schedule, say 3-4 major releases a year?

I think the pace is just about right, though I could even tolerate even more frequent releases.  Less frequent releases would actually be a somewhat irritating to me.  For example, I have a language change in 2.081 that I really need in LDC today, but it looks like I'm going to have to wait at least 4 months to get it.

IMO, the current schedule is working out quite well.

Mike

On Monday, 14 May 2018 at 07:20:48 UTC, Joakim wrote:
>
> I thought 6/year was an ambitious schedule when announced and I wonder if it isn't putting too much strain on our few release maintainers, maybe 3-4 releases/year would be a more gradual bump up.

This is what happens to programming langauges and software development, when competition becomes the main game.

Thank god for Redhat - still on gcc 4.8.5 .. god bless them ;-)

On Monday, May 14, 2018 07:20:48 Joakim via Digitalmars-d wrote:
> There have been 6 major releases of dmd over the last year, with ldc trying to keep pace, currently only one release behind. This is a big jump up from the previous release schedule, I see 2 major releases in 2014, 3 in 2015, and 3 in 2016.
>
> There are obviously pros and cons to each pace, and this has been debated internally before, with one of the ldc devs again posting to the Internals mailing list today questioning the current speed.
>
> I thought I'd open it up to the community: now that you've experienced this faster pace, as a user of the D compilers, how do you like it? Would you prefer a slower release schedule, say 3-4 major releases a year?
>
> I thought 6/year was an ambitious schedule when announced and I wonder if it isn't putting too much strain on our few release maintainers, maybe 3-4 releases/year would be a more gradual bump up.

I think that most of us are fine with how it's been going, but a large percentage of the work for putting out each release goes to Martin, and he's been talking about reducing the pace to something more like one major release every 6 months, which I think would be too slow. I don't want to have to wait that long for improvements to Phobos to become available. Quarterly would be okay, I guess, but it's always frustrating when an improvement makes it into Phobos but you can't use it for months, because you have to wait for it to be released - and it's even worse when you want to then be able to build your code with ldc, since they're always behind.

- Jonathan M Davis

On Monday, 14 May 2018 at 07:46:35 UTC, Mike Franklin wrote:
> On Monday, 14 May 2018 at 07:20:48 UTC, Joakim wrote:
>
>> [...]
>
> The post is here: https://forum.dlang.org/post/ingkexhebiaqdzknicvr@forum.dlang.org
> [...]
> Mike

I agree with you. I think the best way is to make it one release every 3 months or so and have a yearly LTS release that people can rely on for stability. On the plus side, I really like the predictable realeases.

On 05/14/2018 03:20 AM, Joakim wrote:
> There have been 6 major releases of dmd over the last year, with ldc trying to keep pace, currently only one release behind. This is a big jump up from the previous release schedule, I see 2 major releases in 2014, 3 in 2015, and 3 in 2016.
> 

This is just a return to the old original pace. It used to be about this often, but improved focus on avoiding regressions and packaging mistakes had a side effect of delaying releases down to as low as 2/year. But the improved "checks and balances and procedures" have finally become streamlined enough that the delays have been overcome and we're back to where we already were.

Personally, I like it. Keep in mind, availability of an update does not mandate immediate upgrading. It's just means its *available*. In an ideal world, improvements should be available immediately. In the real world, we have need to allow for both automated and manual checks for regressions. Therefore, the only things that should delay deployment of a project's new releases are:

A. Automated regression tests (and fixing found regressions).
B. A formal "beta" cycle (and fixing found regressions).
C. The existence of improvements (without improvements, what's the point of a new release?).

If dependent projects/libs have trouble keeping up with an increased rate of releases, that only means that we need better tools for automating the tasks involved in supporting newer releases.

If there's motivation to delay releases, that's a clear indication that dependent projects are in simply need of better automation/processes/etc.

Summary (That's "TL:DR" in hipster parlance): **Available** updates are always a good thing, as long as they're checked for regressions. Any issues keeping up with updates only indicate we have a *good* problem: That the ecosystem has room for "process" improvements and isn't currently being constrained by lack of progress in dependencies.

On Monday, 14 May 2018 at 08:29:30 UTC, Nick Sabalausky (Abscissa) wrote:
> On 05/14/2018 03:20 AM, Joakim wrote:
>> [..]
> Summary (That's "TL:DR" in hipster parlance): **Available** updates are always a good thing, as long as they're checked for regressions. Any issues keeping up with updates only indicate we have a *good* problem: That the ecosystem has room for "process" improvements and isn't currently being constrained by lack of progress in dependencies.

Agree, but I think LTS releases are worth considering. A yearly release that gets only bug fixes would be useful for stability.

Ie, as long as there's no regression problems: If the rate of releases makes us feel like we have an embarrassment of riches, it doesn't mean that we *NEED* fewer releases. It means we need to be more appreciative that there's all those enhancements we don't have to wait for.

On 05/14/2018 04:35 AM, Uknown wrote:
> 
> Agree, but I think LTS releases are worth considering. A yearly release that gets only bug fixes would be useful for stability.

A fair point. I have no disagreement with something like that.

On Monday, 14 May 2018 at 07:53:40 UTC, Jonathan M Davis wrote:
> On Monday, May 14, 2018 07:20:48 Joakim via Digitalmars-d wrote:
>> There have been 6 major releases of dmd over the last year, with ldc trying to keep pace, currently only one release behind. This is a big jump up from the previous release schedule, I see 2 major releases in 2014, 3 in 2015, and 3 in 2016.
>>
>> There are obviously pros and cons to each pace, and this has been debated internally before, with one of the ldc devs again posting to the Internals mailing list today questioning the current speed.
>>
>> I thought I'd open it up to the community: now that you've experienced this faster pace, as a user of the D compilers, how do you like it? Would you prefer a slower release schedule, say 3-4 major releases a year?
>>
>> I thought 6/year was an ambitious schedule when announced and I wonder if it isn't putting too much strain on our few release maintainers, maybe 3-4 releases/year would be a more gradual bump up.
>
> I think that most of us are fine with how it's been going, but a large percentage of the work for putting out each release goes to Martin, and he's been talking about reducing the pace to something more like one major release every 6 months, which I think would be too slow. I don't want to have to wait that long for improvements to Phobos to become available. Quarterly would be okay, I guess, but it's always frustrating when an improvement makes it into Phobos but you can't use it for months, because you have to wait for it to be released - and it's even worse when you want to then be able to build your code with ldc, since they're always behind.
>
> - Jonathan M Davis

Honestly Phobos should be released independently from DMD (But should still be shipped with it of course.)

Library implementations shouldn't wait for the compiler to be available.

That's just my opinion though