Problem/Motivation

Symfony 4.4.0 was released on November 21, 2019. 9.0.x branch should update to this stable version.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Drupal now uses the stable Symfony 4.4 release.

CommentFileSizeAuthor
#16 interdiff.3088754.7-16.txt9.4 KBmikelutz
#16 3088754-16.drupal.patch21.06 KBmikelutz
#7 interdiff.3088754.3-7.txt9.71 KBmikelutz
#7 3088754-7.drupal.patch20.59 KBmikelutz
#3 3088754-3.drupal.patch26.7 KBmikelutz

Comments

alexpott created an issue. See original summary.

mikelutz’s picture

mikelutz
He/Him
Primary language English
Location Michigan, USA
commented
Title: Update to Drupal 9 to non-dev Symfony 4.4 » Update to Drupal 9 to Symfony 4.4.0
Assigned: Unassigned » mikelutz
Priority: Critical » Major
mikelutz’s picture

mikelutz
He/Him
Primary language English
Location Michigan, USA
commented
Assigned: mikelutz » Unassigned
Issue summary: View changes
Status: Active » Needs review
StatusFileSize
new 3088754-3.drupal.patch26.7 KB 
mike@MacBook-Pro /Users/mike/Development/Drupal > composer show "symfony/*"
symfony/browser-kit                v4.4.0  Symfony BrowserKit Component
symfony/class-loader               v3.4.35 Symfony ClassLoader Component
symfony/console                    v4.4.0  Symfony Console Component
symfony/css-selector               v4.4.0  Symfony CssSelector Component
symfony/debug                      v4.4.0  Symfony Debug Component
symfony/dependency-injection       v4.4.0  Symfony DependencyInjection Component
symfony/dom-crawler                v4.4.0  Symfony DomCrawler Component
symfony/error-handler              v4.4.0  Symfony ErrorHandler Component
symfony/event-dispatcher           v4.4.0  Symfony EventDispatcher Component
symfony/event-dispatcher-contracts v1.1.7  Generic abstractions related to dispatching event
symfony/filesystem                 v4.4.0  Symfony Filesystem Component
symfony/finder                     v4.4.0  Symfony Finder Component
symfony/http-foundation            v4.4.0  Symfony HttpFoundation Component
symfony/http-kernel                v4.4.0  Symfony HttpKernel Component
symfony/lock                       v4.4.0  Symfony Lock Component
symfony/mime                       v4.4.0  A library to manipulate MIME messages
symfony/phpunit-bridge             v4.4.0  Symfony PHPUnit Bridge
symfony/polyfill-ctype             v1.12.0 Symfony polyfill for ctype functions
symfony/polyfill-iconv             v1.12.0 Symfony polyfill for the Iconv extension
symfony/polyfill-intl-idn          v1.12.0 Symfony polyfill for intl's idn_to_ascii and idn_to_utf8 functions
symfony/polyfill-mbstring          v1.12.0 Symfony polyfill for the Mbstring extension
symfony/polyfill-php72             v1.12.0 Symfony polyfill backporting some PHP 7.2+ features to lower PHP versions
symfony/polyfill-php73             v1.12.0 Symfony polyfill backporting some PHP 7.3+ features to lower PHP versions
symfony/process                    v4.4.0  Symfony Process Component
symfony/psr-http-message-bridge    v1.2.0  PSR HTTP message bridge
symfony/routing                    v4.4.0  Symfony Routing Component
symfony/serializer                 v4.4.0  Symfony Serializer Component
symfony/service-contracts          v2.0.0  Generic abstractions related to writing services
symfony/translation                v4.4.0  Symfony Translation Component
symfony/translation-contracts      v2.0.0  Generic abstractions related to translation
symfony/validator                  v4.4.0  Symfony Validator Component
symfony/var-dumper                 v4.4.0  Symfony mechanism for exploring and dumping PHP variables
symfony/yaml                       v4.4.0  Symfony Yaml Component

I added symfony/mime and symfony/var-dumper as explicit dependencies (They are already dependencies or dependencies of a dependency of http-kernel). If we don't add them explicitly, they are installed at v5.0.0. This might be fine, http-kernel allows them at ^4.4|^5.0, but because the 5.0 versions lose security support after 8 months, we would be constantly updating them to new minors in the middle of one of our minors, so I prefer to pin them to the LTS version. I also updated the composer.json files to ^4.4.0 from ^4.4 for no particular reason other than aesthetics. My OCD likes having the minimum patch version explicitly stated, even when it is 0.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
commented

For me I think we should only include the patch version when it is significant. In an ideal world we'd be doing min / max testing and trying to be a compatible with PHP ecosystem as possible.

Listing indirect dependencies in our composer.json is also pretty interesting - I get the rationale - but also doesn't that mean we should be doing this for all our dependencies. Listing things we're not dependent on can backfire. What happens if Symfony remove a dependency (unlikely though that is).

Status: Needs review » Needs work

The last submitted patch, 3: 3088754-3.drupal.patch, failed testing. View results

andypost’s picture

andypost
he/him
Primary language Russian
commented
Related issues: +#1451320: Evaluate Symfony2's Finder Component to simplify file handling
mikelutz’s picture

mikelutz
He/Him
Primary language English
Location Michigan, USA
commented
Status: Needs work » Needs review
StatusFileSize
new 3088754-7.drupal.patch20.59 KB
new interdiff.3088754.3-7.txt9.71 KB

Alright, removing the patch from the composer.json.

Rather than explicitly requiring var-dumper and mime at ^4, we now conflict with >=5, so if symfony removes one, composer will be able to uninstall it.

Also https://github.com/symfony/symfony/pull/34366 added single quotes around RedirectResponse's meta refresh tag, so there's a regex update to the tests to take that into account.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
commented 
+++ b/core/composer.json
@@ -50,7 +50,9 @@
+        "symfony/mime": ">=5",
+        "symfony/var-dumper": ">=5"

Yep but we don't do we... it feels as though composer should be able to say prefer-lts

mikelutz’s picture

mikelutz
He/Him
Primary language English
Location Michigan, USA
commented

As I see it, we can

  1. Allow symfony/var-dumper and symfony/mime at 5.0, but know we will have to do a minor version bump before release and again in November 2020 in order to receive security updates through June 2021
  2. Explicitly require it at ^4 so that we can get security updates without requiring a minor version bump through the life of Drupal 9
  3. Conflict with =>5 so that we can get security updates without requiring a minor version bump through the life of Drupal 9
  4. Whatever @alexpott says in the next post, because somehow he always comes up with one more option than I do :-p

Talk amongst yourselves, and tell me what to roll into the next patch. :-)

catch’s picture

catch
he/him
Primary language English
commented

So for this issue, I think either 1 or 3 is fine and don't have a strong preference. However we should open a beta blocking issue to decide which one we go with for release (or option 4 if it materialises).

mikelutz’s picture

mikelutz
He/Him
Primary language English
Location Michigan, USA
commented

The patch in #7 currently implements option #9.3

krzysztof domański’s picture

krzysztof domański
Location Poland
commented
Issue tags: +Needs change record updates

I have attached this issue to CR Drupal 9 now requires Symfony 4.4.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
commented

I've not got another option atm. I think I dislike the conflicts more than explicitly requiring var-dumper and mime at ^4.4 - because we really don't conflict with them. My fear of option 1 would be that we add one of these as a dep during the 9 cycle and then we have to downgrade or do ^4|^5 in our own composer.json. So perhaps I'm back to the approach taken in #3. As the least worst outcome whilst we ship a lock file and recommended versions.

eric_a’s picture

eric_a commented

Rather than explicitly requiring var-dumper and mime at ^4, we now conflict with >=5, so if symfony removes one, composer will be able to uninstall it.

Yep but we don't do we... it feels as though composer should be able to say prefer-lts

How about declaring conflicts with all of 5.0, 5.1, 5.2, 5.3? Symfony has planned 5.4 (and 6.4) to be long-term support, and last minor.

eric_a’s picture

eric_a commented

because we really don't conflict with them

Ah, right.

mikelutz’s picture

mikelutz
He/Him
Primary language English
Location Michigan, USA
commented
StatusFileSize
new 3088754-16.drupal.patch21.06 KB
new interdiff.3088754.7-16.txt9.4 KB

New patch removing all conflicts and just allowing the 5.0 packages to be installed.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
commented
Status: Needs review » Reviewed & tested by the community
Related issues: +#3096781: symfony/mime and symfony/var-dumper versions are on 5.1.7 (not an LTS) and therefore have gaps in security coverage relative to Drupal minors

This looks great. Thanks @mikelutz for bearing with us while we came to a decision. Or in this case a punt - I created #3096781: symfony/mime and symfony/var-dumper versions are on 5.1.7 (not an LTS) and therefore have gaps in security coverage relative to Drupal minors

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
commented

Crediting people who contributed to the issue discussion and D9readiness meeting discussion.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
commented
Status: Reviewed & tested by the community » Fixed
Issue tags: -Needs change record updates

Committed this because it helps everyone having the composer stuff at the correct versions.

Committed 35bbac2 and pushed to 9.0.x. Thanks!

  • alexpott committed 35bbac2 on 9.0.x 
    Issue #3088754 by mikelutz, alexpott, Eric_A, catch, Krzysztof Domański...
krzysztof domański’s picture

krzysztof domański
Location Poland
commented
Issue tags: +9.0.0 release notes, +9.0.0 highlights

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.