DIP 1013: The Deprecation Process -- Community Review Round 1

[Jonathan M Davis]

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