Drupal 11 release

opened MR!10 against 2.x and MR!11 against 8.x-1.x

MR !10 is ready for review.

Changes looks good to me, hence RTBC.

8.x-1.0 will not be ported to D11. It is for legacy support only. Thus, MR11 is not needed and won't be used.

MR10 is almost all out of scope - most of the changes have nothing to D11 compatibility. Other than changing the version dependencies. And none of the changes are explained in this issue.

For coding standards changes, please open a new issue. Likewise for other changes not related to D11 compatibility.

Also, most of MR10 is adding back Context classes that were deliberately removed from 2.0.x. That should not be done. Read the deprecation notices in the code you're trying to add - those notices explicitly say the code is intended to be removed from 2.0.x

ankitv18 → changed the visibility of the branch 3449149-drupal-11-release to hidden.

ankitv18 → changed the visibility of the branch 3449149-drupal-11-release-8.x-1.x to hidden.

Please review MR!12

As an example of what I'm asking:

-  public function validatedBy() {
+  public function validatedBy(): string {

Why is this done? It's not wrong to add a return value type hint, but it's not required for D11.
https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Validatio...

If return type hints are to be added then IMO they should be done all at once, per class, rather than method-by-method one at a time. That's what I have done in the past, because adding type hints has the possibility of breaking code that extends these classes and also may require a minimum PHP version, thus breaking sites running under a lower PHP version.

-    $assert->fieldValueEquals('data[value]', $context_definition->getDefaultValue());
+    $assert->fieldValueEquals('data[value]', (string) $context_definition->getDefaultValue());

Likewise here. The context definition object explicitly defines data types for each value, and the return of getDefaultValue() will always be the correct data type. Why does the return need to be cast? If it is to satisfy static analysis, then I would say we shouldn't do this. If the return value is actually wrong and needs to be cast for the test to work, then there's a problem elsewhere that needs to be solved rather than just having the test coerce the type.

I opened 📌 [10.3] New method getLabel() on FieldItemDataDefinition Needs review for an issue that fixes a core change made in Drupal 10.3. That is not part of making this module D11 compliant.

@TR I believe drupal11 updated with symfony/validator:^7.1 which results out for this change https://github.com/symfony/validator/blob/7.1/Constraint.php#L272 (because of this I've made all those changes as we are using same method name which causing a problem here)
With symfony/validator 6 version there isn't typehint

Drupal 11.0.x composer.lock: https://git.drupalcode.org/project/drupal/-/blob/11.0.x/composer.lock?re...
11.x composer.lock: https://git.drupalcode.org/project/drupal/-/blob/11.x/composer.lock?ref_...

Yeah, turns out api.drupal.org has some very outdated documentation. Drupal core was changed 3 months ago to add that type hint to the parent class, but that still doesn't show in the documentation on api.drupal.org.

For more details: https://drupal.slack.com/archives/C220WV2TW/p1719173216196289

The core commit that changed this for D11 was 📌 Symfony deprecations in Constraint plugins Fixed

chandu7929 → changed the visibility of the branch 3449149-drupal-11-release to active.

I opened up a new issue for the validateBy() change. See 📌 [11] Symfony deprecations in Constraint plugins Active

Added related issue for the dependency changes.

MR testing is now turned on for D11 and it shows that this module is now currently working in D11.

None of the casts in the above MR are needed.
Most of the changes were D10 changes, not D11.
Regardless, nothing left to do here.

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