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.

Reply via email to