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.
Comments
Comment #2
catchComment #3
bojanz CreditAttribution: bojanz at Centarro for Adapt commentedLooks 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).
Comment #4
jibranWe can't update to twig 2 because it requires
php: ^7.0
. Update IS accordingly.Comment #5
jibranComment #6
tim.plunkettAnswer 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
Comment #7
AdamPS CreditAttribution: AdamPS at AlbanyWeb commentedChanging 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.
Comment #8
xjmAdding the issue for Twig 2.x to the IS.
Comment #9
Mile23Trying 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/mlZX7Comment #10
andypostComment #11
Mile23I made an issue about #9: #2919410: Drupal 8 is not compatible with PHP 5.5.9
Comment #12
HongPong CreditAttribution: HongPong at kor group commentedIs 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
Comment #13
Mile23Drupal'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.*
Comment #14
effulgentsia CreditAttribution: effulgentsia at Acquia commentedPer #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.
Comment #17
Gábor HojtsyOpened #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).
Comment #20
andypostCMF routing has own issue #2917331: Decouple from Symfony CMF
Comment #21
catchAsked a question about the differently-versioned Symfony components https://github.com/symfony/psr-http-message-bridge/issues/76
Comment #23
xjmI think https://www.drupal.org/core/dependencies resolves this issue along with our Drupal 9 and 10 schedule/plans.
Comment #24
catchYes 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.