Update 10.3 release notes to indicate Rules module is not compatible

FWIW the vast majority of Rules usage stats is from Drupal 7.

Sure, but that applies to Drupal core as well since 7.x is still the largest install base. Rules is still a fairly widely used module, and having it installed on 10.3 causes things to crash and burn in spectacular fashion.

Of course, people should always keep backups and test updates on a dev/staging site before upgrading live sites but as you see by the early reports linked above that isn't always happening.

I suppose there is a question around whether core release notes should be responsible for listing all known incompatibilities, and I would say the answer is no...but there could be exceptions.

My sites will continue to run 10.2.x until an update for Rules is available (or a replacement is found) so I'm just trying to help others avoid a ton of frustration here.

All I meant is that there are not 120K installs of Rules that could be affected by this, it's more like 13K → .

Updating release notes is not enough as there is evidence many do not read them. If 10.3 introduced a regression (Did it? Could other modules be affected?) we need an issue to address that. This could become that issue.

I mean "a backward compatibility break", not a "regression".

10.3 does appear to introduce breaking changes and other modules could certainly be affected.

https://www.drupal.org/project/rules/issues/3454056#comment-15652473 📌 [10.3] Update ConditionManager to support PHP Attributes Active

So the issue comes from extending one of core's plugin managers and overriding the protected getDiscovery method. The backwards compatibility policy does not include php classes → (except base classes) nor protected methods → .

That said, there are a fair few contrib modules that seem to be overriding this same method.

So the issue comes from extending one of core's plugin managers and overriding the protected getDiscovery method. The backwards compatibility policy does not include php classes (except base classes) nor protected methods.

Really, you can't extend a core plugin type without implementing PluginManagerBase::getDiscovery() (or in this case, overriding DefaultPluginManager::getDiscovery()). If you don't implement discovery, you can't find the annotation/attribute classes that define your plugin extensions - you will only get the default core annotation/attribute classes and thus can not add or modify any of these defining properties of plugins.

So to fall back on "not core's problem because the discovery method is protected" is a bit of a cop out. Either Drupal is supposed to be extensible or it isn't. And if it is, then any function needed by subclasses for this extension is fair game. If it wasn't supposed to be overridden then it should have been marked private.

Regardless, this core change from annotations to attributes could have very easily been done in a manner that DIDN'T break contrib. Specifically, in order to be backwards compatible, ALL core plugins should have retained their annotation. Annotation appears in the docblock of the plugin, so if the plugin manager is looking for attributes then it will still find attributes and ignore the annotation. But if the plugin manager (or overridden plugin manager) doesn't have the D10.3 changes yet, it would still work because it would still find the annotations. Then the annotations could have been dropped in D11.

Putting all the BC burden into the core plugin manager implementations only works if the plugin managers are never extended.

And while adding attributes to the core plugins doesn't break BC, removing the annotations from those core plugins DOES. I suppose you could say that since annotations are just code comments, removing them is perfectly allowed between minor point versions, but really it was not necessary and wouldn't have broken anything to leave them in there. And would have avoided this issue.

on configuration import also getting below error on rules.

In DiscoveryTrait.php line 53:

The "entity_bundle:node" plugin does not exist. Valid plugin IDs for Drupal\rules\Core\ConditionManager are: rules_data_comparison, rules_data_is_empty, rules_list_contains, rules_list_count_is, rules_enti
ty_has_field, rules_entity_is_new, rules_entity_is_of_bundle, rules_entity_is_of_type, rules_ip_is_banned, rules_node_is_of_type, rules_node_is_promoted, rules_node_is_published, rules_node_is_sticky, rule
s_path_alias_exists, rules_path_has_alias, rules_text_comparison, rules_entity_field_access, rules_user_has_role, rules_user_is_blocked, webform