Problem/Motivation
Splitting this out from #2608062: [policy, no patch] Pre-requisites for opening Drupal 9 since it's a fairly large change from previous major release cycles.
A couple of weeks ago I did some serious triage of the Drupal 9 queue. Between moving some longstanding feature addition/removals to the ideas queue, marking a few things duplicate, and moving a lot of issues that were abandoned in 2013 and 2014 in 8.x code freezes and betas back to 8.x due to eligibility for minor releases, we're now down to a grand total of around a dozen issues.
What's remaining falls into the following categories:
1. Removing backwards compatibility layers that have been added to 8.x
2. A small number of minor impact, medium-to-large disruption @internal API changes which don't seem worth doing in a minor release (for example #2346093: Remove views module weight or #2799911: Make the Connection parameter the first parameter in Select Query Builder.
3. Actual public API breaks, which are either hard to do in minor releases or haven't been triaged back to 8.x yet.
Between our reasonably loose bc policy for minor releases, our slowly improving mechanisms for providing bc for various kinds of changes, and the ability to provide completely new functionality in minor releases via experimental modules, it should be possible to do the vast majority of change we used to do in major releases in minor releases.
#2608062: [policy, no patch] Pre-requisites for opening Drupal 9 outlines several problems we've had with previous major releases, and proposes doing more work before opening the branch to mitigate them.
There are other issues once major versions are released though:
1. Divergence from the previous major branch means that contrib modules have to go through multi-week or multi-month porting cycles before they're stable.
2. While new sites start getting built soon after release to at least some extent, existing sites often wait years to upgrade - as evidenced by the still fairly sticky 10,000 5.x sites, 100,000 6.x sites and 1,000,000 7.x sites reporting back to Drupal.org. The migration path to 8.x isn't the only part of this, otherwise those 5.x/6.x sites would have migrated to 7.x by now.
3. This then results in some sites never upgrading. Either they move away from Drupal, or they skip a major release or three.
4. 7.x spent about a year after release to get to a working upgrade path with no critical bugs. 8.x doesn't have stable upgrade paths from 6.x or 7.x yet either. So even if people wanted to migrate, they can't without a lot of extra work at the moment.
Proposed resolution
Attempt to offer a continuous upgrade path between major versions. See https://speakerdeck.com/nicolasgrekas/how-symfony-3-dot-0-moves-forward-... for how Symfony does it, although they don't have some problems that we do, like needing to worry about content entities etc.
This means:
- 8.LAST.x comes out at the same time (or within a month) of 9.0.x
- Relative to 8.LAST.x, 9.0.x only:
- Removes deprecations
- Makes @internal API changes that are technically eligible for a minor but we'd prefer not to do in a minor.
- There may be cases where there's a necessary API change which absolutely cannot be made without a bc break between majors (i.e. via creating a parallel API and deprecating the old one). Should such a case come up, this would need to be discussed case by case as to whether it could be included.
- We add a feature to support a more flexible core compatibility, so that contrib and custom modules can work with both 8.x and 9.x without branching.
- 9.1.x starts the process again until we reach 10.0.x
The benefits of this are:
1. New sites can immediately use 9.0.x - 99.9% of modules should 'just work'
2. Existing sites should be able to update from 8.LAST.x to 9.0.x with minimally more work than between minor releases. There might be exceptions if they're using a deprecated module (like blog from 7.x-8.x) but the removed module in contrib would at least run on the new version.
3. Due to this, 6.x and 7.x sites should be able to migrate to 8.x towards the end of the 8.x cycle, in the knowledge that they'll be able to quickly hop from there to 9.x, rather than immediately be on another obsolescent release with another chasm of an upgrade path.
4. Contrib maintainers can do a small port every six months, and never a massive port if they don't want to.
5. Once we get to the 9.x-10.x transition, apart from any remaining sticky 6.x or 7.x sites, the bulk of Drupal sites will be able to keep up with each major release. This could allow us to do scheduled major releases as well as minor ones (Symfony just started doing this with a two year cycle).
The drawbacks are:
1. Some things will be hard or impossible to provide bc layers for - however we've not found those yet. Even in those cases, it should usually be possible to build a completely parallel system and leave the old one in place.
2. Major versions are no longer 'big bang' releases - this is also a benefit though.
