On Monday, 2 April 2018 at 07:05:45 UTC, Mike Parker wrote:
> DIP 1013 is titled "The Deprecation Process".
>
> https://github.com/dlang/DIPs/blob/d8f6bfa1810c9774bd7d3b3dc6a7a6776ed5e17e/DIPs/DIP1013.md

It's good to have this formalized as relying on authoritative review on a per-case basis doesn't scale.

- I'd urge you to make this process as simple as possible, and plan for managing and automation.

  Right now it involves several steps over ~2 years requiring updates to separate repos.
  In particular for language changes that require specialized compiler changes,
  such changes cannot be easily done by anyone but the original author.
  Similarily for library changes we're mostly relying on a single person to manage deprecations.

- It seems that the language features section does not yet mention https://dlang.org/spec/spec.html updates.
  https://github.com/dlang/DIPs/blob/d8f6bfa1810c9774bd7d3b3dc6a7a6776ed5e17e/DIPs/DIP1013.md#language-features

On Tuesday, April 24, 2018 16:39:27 Martin Nowak via Digitalmars-d wrote:
> On Wednesday, 18 April 2018 at 12:40:44 UTC, Jonathan M Davis
>
> wrote:
> > 2. Somewhere, it should state that the goal is for the typical deprecation cycle for a symbol to last approximately two years and that the number of releases was picked on the assumption that we would have approximately 5 - 6 major releases a year. So, if at some point in the future, the typical number of releases in a year changes for whatever reason, the number of releases of the deprecation cycle should then be adjusted so that the deprecation cycle stays approximately two years long.
>
> At the moment we have a clear bi-monthly release cycle (1st of
> every odd month).
>
> In the long-run I'd like to transition to one major releases
> every 6 months and strictly non-breaking, non-deprecating point
> releases every 2 months. So far there wasn't much interest in the
> necessary development adjustments though.
> https://forum.dlang.org/thread/drcekmxvfszpwifbukzk@forum.dlang.org

Honestly, I'd hate to have major releases be that infrequent. It can already be annoying enough when something that doesn't get added doesn't end up being released for a two or three months, depending on the timing. The slower the turnaround time, the longer it is before we can take advantage of any improvements. If we were going to do fewer releases, I'd much rather see us do less with minor releases than spread out major releases more.

Regardless, if we do change the rate of major releases, then it makes no sense to retain the same number of major releases for the deprecation cycle. Having them be release-based rather than date-based isn't necessarily a problem, but the overall length of time should stay roughly the same even if the rate of releases changes.

- Jonathan M Davis

On Tuesday, 24 April 2018 at 17:02:50 UTC, Jonathan M Davis wrote:
> Honestly, I'd hate to have major releases be that infrequent. It can already be annoying enough when something that doesn't get added doesn't end up being released for a two or three months, depending on the timing. The slower the turnaround time, the longer it is before we can take advantage of any improvements. If we were going to do fewer releases, I'd much rather see us do less with minor releases than spread out major releases more.

Please read all the info, in particular semver.org. I'd argue for strictly non-breaking backwards-compatible additions in minor releases, which should (could) be most phobos additions.

Not breaking anything with an addition is of course a double-edged sword. Still it would give us a cleaner distinction where deprecations et.al. are only to be expected every 6 months with a major release, while bi-monthly minor releases remained fully backwards compatible.
This seems to hit a better balance between regularly releasing new stuff and causing update churn. In particular since deprecations are on a much longer schedule, it makes sense to batch them anyhow.

TL;DR same rate of improvements, less frequent rate of deprecations and required code changes