Mainly just a reminder but also time to straighten our release timings
a bit.
Part of why 2.075.0 got delayed by several weeks is due to bad timing
of complex PRs, but also due to late beta testing and bug reporting.

To make things simpler I want to propose new fixed dates for releases.

# Fixed release schedule

Branching and Betas are scheduled for the 15th of ever even month:
    2017-08-15, 2017-10-15, 2017-12-15

Releases are scheduled for the 1st of ever odd month:
    2017-09-01, 2017-11-01, 2018-01-01

# Use milestones for sibling PRs

Please try to ensure that features are merged completely (with docs and everthing) before we're branching. Assign related PRs to milestones so we avoid releasing incomplete features.

We clearly need to improve our PR review throughput and delays, but
please do not use milestones to get your feature merged or to plan
your personal timelines. We have a Trello Boards for planning
(https://trello.com/dlang).
We cannot arbitrate lots of unclear discussions or review and merge
stuck PRs when preparing a release. Also releases happen fairly often.
If your feature misses a release, catch the next one.

# Use stable for fixes

Bugfixes and in particular regression fixes should always target stable. Only when a bugfix seems risky, it might be better to target master first to get an extended testing period.

Fixes are regularly merged back from stable into master, usually no extra intervention is needed.

Bugs that got just recently introduced in master need to be addressed in master. Assign such PRs to milestones so we don't miss to merge them before the beta/release.

# Use master for features

Features and API changes (deprecations, removals, etc.) should always target master, they will be included in the upcoming release.


Let me know if you have any comments or questions.

- -Martin