[policy, no patch] Drupal 9 contingency planning

Problem/Motivation

Our current plan is to release Drupal 9 on June 3rd 2020, but with a fallback to December 2020 if this is impossible (see https://dri.es/plan-for-drupal-9). However, the details of this have not been entirely fleshed out and I have a proposal for a slight modification. Only just came up with this particular version after a brief discussion with xjm, although there's been related discussion on #3007300: [META] Release Drupal 9 on June 3 2020.

Drupal 9 needs a longer beta phase than a regular minor release, so this would need to start March-2020 to give plenty of time for contrib modules and early site-testers to have a stable target to test against. However once we release a beta, we're on a hard countdown to release, meaning we need to be sure that Drupal 9.0.0 is pretty much releasable before cutting the beta: #3079680: [META] Requirements for tagging Drupal 9.0.0-beta1.

This creates quite a hard cliff-edge where if we haven't met the beta requirements three months before the release date, we need to slip all the way to December. Various possibilities if we end up in that position involve: slipping the date, squeezing the beta period shorter, or releasing a beta despite blocking issues being outstanding - none of these are good. Also the closer we get to the date, if we're unsure what comes next, it will make it harder to address whichever issues are outstanding.

What we really want is to release the Drupal 9 beta only once we're confident there's a smooth path to release (including confidence for sites that need to update), but not to artificially hold off the date by six months either.

Regardless of what's happening with Drupal 9, Drupal 8.9.0 still has to come out on June 3rd, and as a regular minor release, its alpha/beta period doesn't actually need to start until mid-April. We can also commit critical bug fixes during the alpha/beta changes with small API additions and deprecations as needed.

One 8.9.0 is released though, we can't commit new API additions, deprecations, or updates to patch releases without jeopardising the stability of what is supposed to be an LTS release.

Proposed resolution

Instead of the two dates, add an additional fallback date in the middle, the plan would then look something like this:

1. If Drupal 9 is ready for beta in March, all is good and there's no contingency.

2. If Drupal 9 misses March beta, Drupal 8.9.0 still has to come out on June 3rd. If all critical Drupal 9 blockers are resolved by the 8.9.0 beta window, start the Drupal 9 beta on one of those windows. We still need a longer beta period for Drupal 9, so this would mean an August/September release date (tbd, but we could pick when the final cut-off and release dates are now).

3. If we don't have a releasable/beta Drupal 9 by the time 8.9.0 is out, this is likely because there is an intractable issue which may require deprecations or new APIs, or new update path changes to be added to Drupal 8.9.x. This means we need to allow for releasing Drupal 8.10.x, which will have to happen December 2nd anyway, so slip the Drupal 9 date to December.

The idea being this gives us the combination of certainty that we're not jumping the gun, less of a cliff edge, but also not a rolling yes/no release date any time between June and December.

Table version of the above, with specific dates:

Remaining tasks

Various sign-offs, and documenting this properly.

User interface changes

API changes

Data model changes

Release notes snippet