Problem/Motivation

We need to figure out what has to be done before 9.x is opened.

#2822727: [policy, no patch] Adopt a continuous API upgrade path for major version changes defines what can happen in 9.x, so does https://dri.es/making-drupal-upgrades-easy-forever.

However the nuts and bolts of what this means and when are still undefined. We should keep a list of them here, but make child issues for each.

Proposed resolution

Decide on a set of things that must should or could be completed in 8.x before 9.x is opened at all. This is a proposal that should be discussed - there are probably some missing, some that are optional that shouldn't be and vice versa but this at least gives us something to talk about:

1. The core migration path from 6.x and 7.x to 8.x must be stable before 9.x is opened. We must decide whether to support direct migrations from 6.x to 9.x (catch thinks we should).

2. Either core migrations from 8.x to 8.x or the ability to upgrade 9.x in the same way as an 8.x minor release (using update.php) must must be stable and documented. Both could be available. If there are two parallel systems in place (for example and old and new path aliasing system, then a migration from one to the other must be available.

3. Core compatibility must be enhanced so that the same release of a module can work with both 8.x and 9.x.

4. 8.x core must not use any deprecated classes, functions or methods, this must be enforced by automated testing.

5. Contrib modules must have access to the same testing tools for deprecations as core.

6. An issue with a core patchmust exist that removes all deprecated classes, functions and methods that can be automated and passes tests.

7. Issues for deprecation and bc-layer removals that can't be automated should have individual issues opened.

8. Critical issues must be triaged, so that any critical issues that would require a minor release of 8.x are fixed before 9.x is opened - this will help to prevent a situation where the 8.x LTS branch has unresolvable critical bugs, since 8.x should only receive patch releases after 9.0.0 is released.

9. Private security issues that affect both 7.x and 8.x must also be fixed in 8.x before 9.x is opened for the same reasons as #8.

10. Experimental modules in 8.x should either move to stable before 9.0.0 is released, or be removed, or somehow their situation clarified. Experimental modules should only be added to 9.x, not to the 8.x LTS release.

11. We must have a clear plan for third party dependencies before 9.x is open. #2899825: Release and support cycles for PHP dependencies.

Remaining tasks

User interface changes

API changes

Data model changes

Comments

catch created an issue. See original summary.

catch’s picture

Issue summary: View changes
effulgentsia’s picture

final 8.x LTS

Are you assuming more than one 8.x LTS? If so, has that been discussed anywhere?

catch’s picture

Should should really be 'final 8.x minor version, which would also be the LTS release'.

Although Symfony ended up with two LTS for 2.7 and 2.8, I think that's because they'd already committed to 2.7 being an LTS, and added 2.8 on top - so even if we time the 8.x LTS for the 9.0.0 release, it could still be the only one.

catch’s picture

Issue summary: View changes
catch’s picture

Issue summary: View changes
catch’s picture

Issue summary: View changes
xjm’s picture

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

catch’s picture

Title: Drupal 9 preparation » [policy, no patch] Pre-requisites for opening Drupal 9
Issue summary: View changes

Re-titling and re-writing the issue summary.

catch’s picture

Issue summary: View changes
catch’s picture

catch’s picture

Issue summary: View changes
catch’s picture

Issue summary: View changes
catch’s picture

Issue summary: View changes
catch’s picture

Issue summary: View changes
klausi’s picture

I like the proposal of getting the latest 8.x development branch as ready as possible before we open 9.x.

I think there is a agreement that we want to get rid of simpletest.module, so we need to convert all web tests to browser tests before we open 9.x. That alone could take a while, probably 1 year?

catch’s picture

Yes that should come under "All deprecated usages removed from 8.x" although at the moment only KernelTestBase is actually marked @deprecated and WebTestBase is not. So an extra step of identifying deprecable code maybe.

Converting hundreds of tests is exactly the sort of thing we don't need to do when transitioning from 8.x to 9.x, so agreed that's something we'd want to do first.

The additional advantage then is that the 8.x LTS test coverage will be as minimally divergent from 9.x as it's possible for it to be (which also goes for any other deprecated usage removal).

klausi’s picture

catch’s picture

Status: Active » Needs review

I think there's enough of a plan here to review now.

catch’s picture

Issue summary: View changes

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Dries’s picture

I've been thinking about this quite a bit and I like this proposal. I think we should declare this to be our desire, but allow ourselves to change our mind (e.g. maybe when modules don't continuously upgrade to the latest APIs, making Drupal 9 a "big bang" release after all).

chx’s picture

> 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)

No because rolling back the router takes more time.

> 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?

No because you need to remove the router.

> Can we release Drupal 9 with a fully working migration path from Drupal 7 and 8?

No because you chased away almost everyone deeply caring for migrate including me.

klausi’s picture

Is there an issue to roll back to routing system yet? Would be interesting to see a compilation of problems we have with it and what the alternative would be. Looking forward to https://events.drupal.org/dublin2016/sessions/routing-drupal-9-and-lesso... but the summary does not give any hints yet :(

pwolanin’s picture

Well, I guess that core conversation will be popular ;-)

@chx - can you clarify here (or in another issue) what it would mean to "remove" the router?

A lot of the code came from D7 in terms of actually doing it efficiently.

chx’s picture

> @chx - can you clarify here (or in another issue) what it would mean to "remove" the router?

Remove all APIs and code depending on route names and for incoming, find the one possible route with a database query. I believe that is possible. For outgoing just use path where needed. Most of the time it's an entity link anyways.

timmillwood’s picture

I feel the biggest pre-requisite would be, do people have time.

catch’s picture

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.

Let's open an issue to discuss 9.x routing. I'm sure there's things we could do in 8.x with bc layers too.

For outgoing just use path where needed. Most of the time it's an entity link anyways.

A lot of this was already done in #2407505: [meta] Finalize the menu links (and other user-entered paths) system and similar issues. We massively pulled back from route names during the 8.x beta, not as much as I'd have liked, but things like the entity:// schema and similar help a lot.

xjm’s picture

andrewmacpherson’s picture

A Drupal 9 branch would allow us to drop (or "reset") the templates, CSS, etc, in the Stable (and Classy?) themes.

xjm’s picture

The one unaddressed point of feedback so far is:

I feel the biggest pre-requisite would be, do people have time.

I don't think this is actually a concern -- we can keep releasing minors until the necessary work is complete. Honestly the work defined here is only a fraction of the work we did for D8's development. Given the new minor version cycle, the one risk associated with not releasing major branch is the degradation of performance and maintainability due to accumulated BC layers. But the thing is, to fix that and release 9.0.0, we still need to provide a working migration path, clean removal of deprecated code, etc. The main difference is that we do everything we can before opening the branch, rather than opening the branch and then letting things spiral out of control for the next two years after that.

Regarding the points in the summary:

  • Timing -- I mostly agree, but I'd say "The earliest possible LTS of 8.x is 8.5.0" rather than 8.6.0 released before 9.x is opened. That means 3 more minors / 18 more months from now. Less than that is probably infeasible; longer than that in the future feels a bit magic eight ball. We can always shift the expectation later since it is "at least".
  • Migration path -- I agree with all this.
  • API changes -- Agree with all of 1-4. Not sure about point 5 though; I would not block opening 9.x on having RTBC BC breaks for non-deprecated code. Such patches/feature branches would be really difficult to maintain. I think such changes are ready when they're ready, and if they don't make 9.x, they don't make 9.x.
  • Feature removals -- not sure about this one, for the same reason as with API changes point 5.
  • Bugs -- absolutely agree. So far we have a good track record over the past year for fixing post-release criticals. We are about 25% of the way through triaging the major queue.
  • Feature additions -- I think the first three points are all things that should be reviewed as part of the checklist for opening 9.x, but I'm not sure whether or not they should block it. I think we can also discuss these things as we get closer to that point. For the fourth point, I think we should actually do what Symfony does and avoid additions in 9.0.x entirely. They should go into 9.1.x.

At DrupalCon Dublin, the framework and release managers met with Nicolas Grekas (one of the Symfony core committers) to discuss how they handle BC and deprecations. (See #2575081-33: [policy, no patch] Use E_USER_DEPRECATED in Drupal 8 minor releases.) Adopting those practices will make a lot of the recommendations here much easier to implement, so I would in turn add adopting those practices as a prerequisite for opening 9.x. I would also add the explicit documentation indicated in #2550249: [policy, then meta] Document @internal APIs both explicitly in phpdoc and implicitly in d.o documentation since that is really entangled with what BC means and what we need to deprecate.

For me, this is close to RTBC, minus the few points above I'm unsure of.

catch’s picture

API changes -- Agree with all of 1-4. Not sure about point 5 though; I would not block opening 9.x on having RTBC BC breaks for non-deprecated code. Such patches/feature branches would be really difficult to maintain. I think such changes are ready when they're ready, and if they don't make 9.x, they don't make 9.x.

I've shifted my position since opening this, and I think we should really only do the following for 9.0.0 in terms of API changes:

1. remove backwards compatibility layers
2. Do @internal API changes that are either too disruptive for a minor, or just happen to land in the branch due to timing (a handful of these comprise most of the 9.x queue now)
3. Remove stable features
4. Vendor library updates if we're unable to do them in a minor (or if they happen to land due to timing)

Also 5. potentially add or stabilize experimental modules.

If we couple this with additionally releasing the 8.x LTS at the same time, that is plenty to do for six months - i.e. it's the same as a normal minor release cycle plus those additions.

But the thing is, to fix that and release 9.0.0, we still need to provide a working migration path, clean removal of deprecated code, etc. The main difference is that we do everything we can before opening the branch, rather than opening the branch and then letting things spiral out of control for the next two years after that.

Yes this is the point. If they have to get done anyway, why not do them up front. The worst that happens is an extra minor release or two of 8.x, vs diverging the major branch piecemeal over a much longer period while the production release stagnates - which is exactly what we did with 7-8 from the moment 8.x was opened in Chicago.

Another thing we should add here is making core compatibility more flexible so that modules can potentially work with both 8.x and 9.x at the same time without branching.

catch’s picture

Just opened #2822727: [policy, no patch] Adopt a continuous API upgrade path for major version changes to thrash out the "what is eligible for 9.x" bit of this.

effulgentsia’s picture

Remove stable features

Should this be scoped down to just "stable features that have already been documented somewhere as deprecated"?

Fabianx’s picture

+1 to #36

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

catch’s picture

catch’s picture

Issue summary: View changes

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.