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

[Martin Nowak]

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