Voting starts in March for the Drupal Association Board election.
This issue exists for defining a set of pre-requisites for opening the 9.x branch. It's not for discussing actual proposed changes in 9.x, plenty of other places to do that.
While we don't have any idea what 9.x is going to look like, we have a pretty good idea about what we can do in Drupal 8. Over time we'll start to accumulate things we can't do in Drupal 8 and will have to wait until 9.x, but we're not there yet. We essentially have a list of one at the moment, which is 'drop deprecated stuff'. The list of 9.x issuesnearly fits on two pages. Probably half of them could be marked duplicate of and another 25% were moved there some time in 8.x code freeze or beta before we had the new release cycle, and would be fine in an 8.x minor.
This isn't the place to do a full retrospective of things that went wrong in the 8.x cycle, but a short list of things it would be good not to repeat gives some background to the suggestions later:
- Having release-blocking technical debt in the development branch, that could have been avoided by fixing things in the stable branch before it opened, or just never added at all
- Multi-year development cycle where core features could not be released
- Bug fixes and smaller enhancements to the stable branch delayed on changes in the development branch
- Releasing without a working upgrade path from either of the previous stable versions
- Feature freezes, code freezes or betas which didn't reflect the state of the code base, and made it unpredictable for people working on core patches or porting contrib modules to know what was still eligible or might require additional porting (this improved during the beta).
- Major API changes happening in parallel, subsystems having to be ported to keep up with each other multiple times, slowing them all down
- Dropping features from core after they had been ported through core API changes for 2-3 years rather than before
I think we should consider having the following goals for 9.x - we might not hit them perfectly, but they'd be a departure from previous release cycles:
- Can we make the time from opening Drupal 9 to 9.0.0 6-9 months? (Drupal 5 took 8 months, Drupal 6 took a year, Drupal 7 and 8 took more than three years each)
- Can we make it so a module ported to the last Drupal 8 minor version (i.e. using no deprecated APIs) will run on Drupal 9 with no or little modification?
- Can we release Drupal 9 with a fully working migration path from Drupal 7 and 8?
- By doing these, can we start encouraging people to update sites from major release to major release instead of skipping a release? This could mean that 7.x sites move to 8.x more than they otherwise would if the 9.x cycle was expected to be 'more of the same'.
To have the shortest possible time between opening the 9.x branch and 9.0.0, this means doing as much of the work up front for 9.x as we can, without the branch being opened yet. The more of that work we can identify and complete as a prerequisite to opening the 9.x branch, the less we have to do to get 9.0.0 released from that point on.
It's very difficult in core development to guarantee that certain things will happen, however we can guarantee that certain things won't happen, like when branches open.
Decide on a set of things that must be completed in 8.x or feature branches, before 9.x is opened at all.
Decide that certain things should either be done in 8.x minor releases or 9.x minor releases, but not targeted for 9.0.0 if they could result in release blocking technical debt.
Agree on steps to make the transition from 8.x to 9.x smoother than the transition from previous releases for both contrib projects and real sites.
Here's some specifics to start:
Regardless of other criteria, I think it's safe enough to say we won't open 9.x until at least 2018 - that gives us at least 3-5 more 8.x minor versions. We can of course revise that upwards depending on how things are going when we get there. People itching to do 9.x-only things can still work in branches before that.
So, could we for example commit to releasing at least 8.6.0 before opening 9.x?
- Migration path
- Complete and stable migration path from Drupal 6 to 8.x, and 7 to 8.x
- Complete and stable migration path from Drupal 8.x to Drupal 8.x
If do these, then the only changes required to get a 6-9, 7-9, and 8-9 migration path will be about porting destination plugins, or source plugins if there's an API change.
We might not want to support 6-9 updates in core, can decide that closer to the time (but again, ideally before we open the branch).
- API changes
- All deprecated usages removed from 8.x
- Major API additions/changes that can be done in 8.x with a bc layer or via parallel subsystems are done there, especially if they're pre-requisites to further changes planned for 9.x.
- Feature branch with all deprecated classes/methods/functions removed exists and passes tests (proves #1 and #2).
- API changes that don't make it into 8.x, but would be eligible for a minor release, either go into 9.0.x with a bc layer or get deferred to 9.1.x to minimise disruption to everything else
- Changes that can only happen in 9.x and which aren't straight removals of deprecations should be ready in an RTBC patch or feature branch, prior to 9.x being opened, so that we can commit them shortly after it does. Also they'll need to demonstrate they really can't be done without a hard break. One example might be a simple rename of a module (unless we find a way to handle bc and upgrade paths for that).
- Feature removals
1. Any features slated for removal in 9.x (equivalents to overlay or openid in 8.x) have a feature branch ready to go with the removal.
2. Same for deprecated features within modules which might not be covered by @deprecated as such. For example if we decided not to bother with core fallbacks for some things which are provided by Views, we could do all of those removals in a feature branch before 9.x is open too. Or move them to a new legacy views fallback module in 8.x and just delete it in 9.x. Similarly if we remove the 6.x migrations, do that up front too.
- Make sure 8.x has a clean slate for critical bugs and 'rate and nature' is manageable. Also make sure the major queue is triaged.
- Feature additions
Review the status of any ongoing core initiatives or experimental modules. Modules that aren't stable yet - should they be stable in 8.x before 9.x opens? Should they be removed in 9.x because they're stagnant? Are there features nearly ready that could go into one more minor 8.x release or is everything major waiting for 9.x?
Consider only adding new features to 9.0.x as experimental modules (assuming they're ready for that), so that bugs in them don't hold up the 9.0.x release, and only at either the beginning or the end of the 9.0.x development cycle so they don't get caught in porting hell (in either direction).
- Open separate policy issues for some of the above items that need more discussion - will be hard to discuss them all in here.
- Start documenting the things we can agree on in the handbook somewhere.
- Keep revisiting the criteria and how far we are towards meeting it at least every minor release cycle.