Problem/Motivation

This was discussed very early on in the 8.x development cycle when we started to bring in PHP components, but it was never really resolved - partly because discussions got dropped, partly because release cycles of the components we were adding weren't clear at the time.

This is coming to a head on #2842431: [policy] Remove PHP 5.5, 5.6 support in Drupal 8.7.

Symfony

Drupal 8 has a six month minor release cycle, we don't have a date for Drupal 9, but let's say it's 2-4 years from the release of Drupal 8.

Symfony has the most predictable release cycle of our dependencies.

Symfony 2.0 was released in 2011, shortly before we started to use some components.

Symfony 3.0 was released 2015.The Symfony 3.4 LTS will lose bugfix support in November 2020 and security support November 2021.

Symfony 4.0 will be released November 2017

Although we updated from Symfony 2 to Symfony 3 during the 8.x release cycle (having announced it at the same time Symfony 3.0 was released), there's no indication whether we'll be able or willing to update to Symfony 4. We may then be in the position of having to stay on the LTS in our development version, or having to start Drupal 9 if we want to keep up with Symfony's release schedule.

Doctrine

With Doctrine there's no scheduled release cycle for Doctrine common that I can find, however a minor release of Doctrine Common (2.8.0) just upped their PHP requirement to 7.1 http://www.doctrine-project.org/2017/07/25/php-7.1-requirement-and-compo... It's not clear when bugfix or security support will be dropped.

@todo: fill out details for the following:

Twig

Twig 2 is already out, when will Twig 1 support end? Twig 2 requires php: ^7.0.
#2572605: Make Drupal 8 optionally working with Twig 2, while keeping its dependency on Twig 1

phpunit

We're already two major phpunit releases behind - 4.8 vs. 5 and 6.

Zend

Guzzle

Symfony CMF routing

Proposed resolution

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
bojanz’s picture

Looks like our main problem is that the dependencies we use abandon PHP versions quicker than we do. Otherwise we could update at least some of them in a minor release.

#2864037: [META] Update core PHP dependencies shows that PHPUnit 5, symfony-cmf/routing 2.0, zendframework/zend-feed 2.8 require PHP 5.6, for example.

(Sidenote: with all of the kernel simplifications I am unsure how much of symfony-cmf/routing we're still using).

jibran’s picture

Issue summary: View changes

We can't update to twig 2 because it requires php: ^7.0. Update IS accordingly.

jibran’s picture

tim.plunkett’s picture

Answer to the sidenote in #3:
Most of our usage of symfony-cmf is for the concept of RouteObjectInterface::ROUTE_OBJECT.
Which is the only reason we still need their UrlMatcher...
The rest is really just the filters and enhancers. Which we customized anyway, see #2883680: Force all route filters and route enhancers to be non-lazy

$ grep -rho "use .*Cmf[^ ;]*" core | sort | uniq -c | sort -nr
  39 use Symfony\Cmf\Component\Routing\RouteObjectInterface
   4 use Symfony\Cmf\Component\Routing\RouteProviderInterface
   3 use Symfony\Cmf\Component\Routing\PagedRouteProviderInterface
   3 use Symfony\Cmf\Component\Routing\NestedMatcher\RouteFilterInterface
   3 use Symfony\Cmf\Component\Routing\Enhancer\RouteEnhancerInterface
   1 use Symfony\Cmf\Component\Routing\VersatileGeneratorInterface
   1 use Symfony\Cmf\Component\Routing\PagedRouteCollection
   1 use Symfony\Cmf\Component\Routing\NestedMatcher\UrlMatcher
   1 use Symfony\Cmf\Component\Routing\LazyRouteCollection
AdamPS’s picture

Changing dependencies can easily cause problems for drush compatibility: see #2906637: [META] Drush and core compatibility is fragile. The long term plan is to drop support for "drush pm-upgrade" and the globally installed drush. In the short term, the alternative (composer seems a favourite) is not yet ready for everyone to use #2845379: Provide optional composer integration but don't force users to understand how to use composer.

In D8.4 there was a concrete example #2874827: Drush 8.x doesn't install Drupal 8.4.x and Drush master doesn't install Drupal 8.3.x and the drush team came to the rescue with some subtle fixes to avoid the problem. This won't necessarily always be easy or even possible (in particular they report not to expect it to work for Symfony 8.4).

Please can anyone in charge of updating a dependency take into account the need to plan and test for maintaining drush compatibility? In severe cases this aspect might even force us to defer a dependency upgrade into a later release (after the alternative of composer was working and hence pm-upgrade could be dropped). Therefore it is vital to consider this aspect as early as possible. Details are in the linked issue.

xjm’s picture

Issue summary: View changes

Adding the issue for Twig 2.x to the IS.

Mile23’s picture

Trying to figure out this: #2898119: Doctrine/Common 2.8 requires PHP ~7.1

I ended up looking at this: https://travis-ci.org/paul-m/drupal_dependency_bounds_test/jobs/287060375

...which shows us a couple of interesting things.

1) Composer can resolve our current 8.4.x dependencies for PHP 5.5.9, even with --prefer-lowest, so yay.

2) Under PHP 5.5.9, PHPUnit ends up failing tests which don't fail under the testbot for some reason. All the failures are related to this message thrown by the Datetime component tests: DateTime::setTimezone(): Can only do this for zones with ID for now This seems to be fixed in PHP 5.5.10: https://bugs.php.net/bug.php?id=45543 and https://3v4l.org/mlZX7

andypost’s picture

Mile23’s picture

HongPong’s picture

Is it possible to write a module with dependencies on newer versions of some symfony libraries than core has? With Symfony 4 out now I wonder if it's possible to write a Symfony 4 based module in Drupal 8.4.

See: https://symfony.com/4 .
Quick demo: https://medium.com/@fabpot/symfony-4-a-quick-demo-da7d32be323
Upgrade guide: https://github.com/symfony/symfony/blob/master/UPGRADE-4.0.md .
Best practices: https://medium.com/@fabpot/symfony-4-best-practices-b4bbd6a9c994
Monolith v micro: https://medium.com/@fabpot/symfony-4-monolith-vs-micro-52dc6b98c0c5
More on bundles https://medium.com/@fabpot/fabien-potencier-4574622d6a7e
Various tutorials: https://symfony.com/blog/symfony-4-a-new-way-to-develop-applications

Mile23’s picture

Drupal's core/composer.json is going to conflict with any module that tries to require newer symfony components.

8.4.x and 8.5.x currently say "symfony/http-foundation": "~3.2.8"

See #2874909: Update Symfony components to 3.3.*

effulgentsia’s picture

With Symfony 4 out now I wonder if it's possible to write a Symfony 4 based module in Drupal 8.4.

Per #13, neither 8.4 core, nor the upcoming 8.5 core are currently compatible with Symfony 4. It would be great to fix that though for 8.6 or as soon as we can. See also #2608496-30: [policy, no patch] Drupal 9 release timing and Drupal 7/8 EOL and #2874198: Create and run dependency regression tests for core.

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.

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

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

Gábor Hojtsy’s picture

Opened #3009213: [META] Update / reconsider PHP dependencies for Drupal 9 to collect all the things that need updating in Drupal 9 (ideally with compatibility in Drupal 8 so we only need to flip the switches with Drupal 9).

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.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.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

andypost’s picture

catch’s picture

Asked a question about the differently-versioned Symfony components https://github.com/symfony/psr-http-message-bridge/issues/76

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

xjm’s picture

I think https://www.drupal.org/core/dependencies resolves this issue along with our Drupal 9 and 10 schedule/plans.

catch’s picture

Status: Active » Closed (outdated)

Yes I think we still have the initial problem (only just keeping up with Symfony LTSes), but by now we've got other issues talking about that. Closing as outdated.