Is D releasing too often?

[Nick Sabalausky (Abscissa)]

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.