Lock Drupal 10.0 on symfony/serializer and symfony/validator 6.2

Is this an issue when using drupal/core-recommended?

Re #4 I don't think so. However, not all people use drupal/core-recommended. Personally, I think it is wrong pattern 💬 ExecutionContext::setNode() method not compatible with symfony/validator interface Closed: works as designed to fix dependency problems with this package.

Ah....apparantly not...

symfony/console: ~v6.2.5
symfony/dependency-injection: ~v6.2.6
symfony/deprecation-contracts: ~v3.2.0
symfony/error-handler: ~v6.2.5
symfony/event-dispatcher: ~v6.2.5
symfony/event-dispatcher-contracts: ~v3.2.0
symfony/http-foundation: ~v6.2.6
symfony/http-kernel: ~v6.2.6
symfony/mime: ~v6.2.5
symfony/polyfill-ctype: ~v1.27.0
symfony/polyfill-iconv: ~v1.27.0
symfony/polyfill-intl-grapheme: ~v1.27.0
symfony/polyfill-intl-idn: ~v1.27.0
symfony/polyfill-intl-normalizer: ~v1.27.0
symfony/polyfill-mbstring: ~v1.27.0
symfony/process: ~v6.2.5
symfony/psr-http-message-bridge: ~v2.1.4
symfony/routing: ~v6.2.5
symfony/serializer: ~v6.2.5
symfony/service-contracts: ~v3.2.0
symfony/string: ~v6.2.5
symfony/translation-contracts: ~v3.2.0
symfony/validator: ~v6.2.5
symfony/var-dumper: ~v6.2.5
symfony/var-exporter: ~v6.2.5
symfony/yaml: ~v6.2.5

https://packagist.org/packages/drupal/core-recommended#10.0.x-dev

So I think we can close this issue as a won't fix?

Or is it a problem that drupal/core without using drupal/core-recommended can still be updated to SF 6.3?

@Chi You are arguing that core should set known working dependency ranges regardless of the specific pinned versions in core-recommended. Am I correct?

It makes sense to me.

You are arguing that core should set known working dependency ranges regardless of the specific pinned versions in core-recommended.

I would argue that setting known working dependency ranges is the essential of core-recommended and that if you want to "go rogue" on drupal/core you can, but at your own risk.

But let's let a core committer chime in on that, putting this on NR for that reason (adn the fact that TestBot turned green).

core-recommended is optional package. It pins dependencies to those that are used for testing Drupal core on drupal.org CI.
So that it may potentially help to avoid issues when third-party packages accidentally break BC promises in non-major release. If I am not mistaken, it was originally created by webflow and then moved to core repository as part of Composer initiative.

Anyway, given it is just an option, drupal/core should always clearly declare supported dependencies.

The only related left open to detect regressions but other issues are closed like #2976407: Use drupalci.yml for composer dependency min/max testing - DO NOT COMMIT →

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

bot is checking against 10.1.x so excluding this one from the list of issues

I am using D10.0-dev and have just hit this problem. From #10 I have no intention to "go rogue", I was just following the normal process of setting up a site using the steps that have been in place for several years. From https://packagist.org/packages/drupal/core-recommended#10.0.x-dev are you saying I need to add composer require drupal/core-recommended into the set-up steps?

The constraints should be 6.2.*, so that of course, any site can install a lower version of SF 6.2 components if desired.

@jonathan1055 The official install instructions → lead to having core-recommended by dint of using composer create-project drupal/recommended-project my_site_name_dir. As far as I know those have been the instructions for several years.

I am making this NW based on #16.

Darren Oh → made their first commit to this issue’s fork.

~6.2 is an incorrect constraint. It allows 6.3 to install.

Version appears locked.

Do we need to lock all of Symfony on 6.2, or just the problematic components?

Another thought: the "updated deps" CI run should catch this, no? https://www.drupal.org/pift-ci-job/2692265 → implies that PHPStan has picked up on this - if we fix the "updated deps" run with the minimum amount of fixes and constraints, is that better than locking Symfony entirely to 6.2?

The policy is that only Symfony 6.2 is supported on Drupal 10.0, so it makes sense to lock all of Symfony to that version.

If we lock symfony/validator to ~6.2.0 and fix the PHPStan warnings, we should be able to get Drupal 10.0 running on Symfony 6.3 except for the validator component - let's see...

The policy is that only Symfony 6.2 is supported on Drupal 10.0

Where is this policy?

Symfony 6.3 should be backward compatible with 6.2, *except* in the case where we used internal Symfony APIs, which we have done in the typed data validator, and hence the issues that we are seeing here.

Let's also lock symfony/serializer, and backport some return type fix comments from 10.1.x.

A lesson for the future is that we should backport as many fixes as possible when we update to a new Symfony version, a lot of this is taken from 📌 Update to Symfony 6.3 Fixed

The policy was stated by Nathaniel Catchpole and quoted in the description of this issue. This issue was opened because the core committers refused to accept a backport.

@Darren Oh we won't backport the actual update to Symfony 6.3, this doesn't mean we can't backport compatibility fixes if they're otherwise fine for a patch release - these are two different things.

More void return declarations.

Updating the title for the suggested new approach.

Spokje → closed merge request !4132

Another reason for doing it this way: Symfony 6.4 will be released in November, when Drupal 10.0 goes out of support. There's a good chance that Symfony 6.4 will bring along some similar issues; users who update their components to Symfony 6.4 will run into these issues, and really we want them to update to Drupal 10.1 or 10.2 - whereas if we locked on Symfony 6.2, users could stay on Drupal 10.0 for longer.

#37 makes complete sense.

OK I think this is the best we can do - pin the ones where we're subclassing internal stuff (not by our own choice, we tried to get upstream changes so we wouldn't have to do that and they were rejected), and suppress phpcs for the rest.

Committed 70853dd and pushed to 10.0.x. Thanks!

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