[meta] Rules deprecated code

Sure, we can increase the number. But this is something that's going to have to be done frequently, because core has declared that deprecations can be added at any time now, so this number can change on a day-by-day basis ...

Of the new deprecations:
Providing context definitions via the "context" key is deprecated in Drupal 8.7.x and will be removed before Drupal 9.0.0. Use the "context_definitions" key instead.
This one is the subject of an open issue that explains why we can't get rid of it yet: #3030295: 'context' deprecated in Rules @Condition annotation

Constructing a ContextDefinition object for an entity type is deprecated in Drupal 8.6.0. Use Drupal\Core\Plugin\Context\EntityContextDefinition instead.
This is a core change that is really just wrong and will pose existential problems for Rules. I have raised this point before in the core queue, to deaf ears. The whole premise of Rules is that because of the Typed Data API, we can treat all typed data equally. If we need to program huge switch blocks everywhere to do something different for each different datatype, then all the power, simplicity and elegance of reflection-based code is lost. This change means we CAN'T simply get the context for the data type in a type-agnostic way - we have to get the data, determine the data type, then do different things depending on the type of the data. That's just wrong. The root problem is that core Drupal focuses on Entities to the exclusion of everything else, so they keep putting things into the Entity API that really should belong in the Typed Data API and apply to all data types. The sad thing is, it would be EASY to support both ContextDefinition for all types including entities as well as the specialized EntityContextDefinition for only entities, but core has decided that entity contexts are now going to diverge from field contexts and from contexts for all other data types. I frankly don't have the bandwidth to fight this in core - it needs a sit-down discussion with the core maintainers and I am not invited to those meetings. I talked with @fago about this last year, and I think he agreed with me, but he has not been involved with Rules for a long time now and I don't think he has the time to deal with it either (although he would certainly be more successful influencing core...)

Apart from these, all those other deprecations share the same problem. The whole core deprecation scheme coupled with core "semantic versioning" is a huge problem for contrib modules - if a deprecation isn't backported to ALL the currently-supported versions of Drupal, that means contrib CAN'T remove the deprecated usage immediately. The only choices are:

1. Code to the API of the lowest version of core that needs to be supported. This means (currently) that anything that is deprecated in 8.7.x or higher cannot be changed yet. This also means that it can be changed only when 8.7.x becomes unsupported, which Is when 9.0.0 is released. Thus, full 9.0.x support CAN'T be added until 9.0.x is officially released. Likewise, things deprecated in 8.8.x need to be supported until 8.8.x is no longer supported, which means when 8.10.x gets released >1 year from now (and 6 months after 9.0.0). The notion that a module can work in both D8 and D9 is not realistic because of this.
2. Create and maintain separate Rules branches for each version of core. This is also problematic - what do we name them, and how does anyone know what version they need? If contrib module versions were allowed to support versions like, e.g. 8.7.x-3.0 and 8.8.x-3.0, then we would be able to make a clear relationship between core versions (8.7.x and 8.8.x respectively) and Rules versions, but we would still have to create and maintain two or three separate branches. If we use the current naming, we will have to have different minor releases for each core version, AND we will have to maintain separate branches for each minor release because core may make API changes between core point release. So Rules 8.x-3.0-alpha5 will work on core 8.6.x, 8.x-3.0-alpha6 will work on core 8.7.x, Rules 8.x-3.0-alpha7 might be a feature release, unrelated to a new core version, 8.x-3.0-alpha8 might work on core 8.8.x, etc. These are TAGS, so then what do we call all these necessary BRANCHES? We have to have separate branches, but we can't call them all 8.x-3.x. And we can't call them 8.x-3.0.x, 8.x-3.1.x, etc, because Drupal is not set up to support that, etc.

I am sticking with 1) for now because I can't justify abandoning sites that are using Rules on currently-supported versions of core. But also, given the lack of community support for this project, I don't have the time or the motivation to create and maintain many different 8.x-3.x branches in order to support multiple versions of D8 core. I suspect that many other contrib modules will go the other way - just code to the most RECENT API and abandon any existing sites. That trend has been building for years in the Drupal community, and is reinforced by the deprecations testing because that puts a lot of pressure on module maintainers to fix deprecations IMMEDIATELY (even thought that is opposite of what "deprecation" should mean) but I think it makes a mockery of the Drupal community's claim to "support" several version of D8/D9. Why should I pick Drupal for an organization if there is absolutely no long-term-support on any version, and if the only way to keep it running is to aggressively and constantly spend time and money to keep upgrading everything every few months?

If I'm wrong about all of this or if there's a better way to do things in contrib then I would REALLY like to know because right now I don't see any alternative.

I could really use some help here, someone to participate in the core Drupal discussions and address the needs of contrib modules in general and Rules in particular. I already have far too much on my plate just dealing with Rules etc. - it's a full time job just to keep pace with core changes, let alone accomplish anything new in Rules. And I am NOT working full time on this - I'm just a volunteer who is doing this in my spare time (which comes and goes).

Oh, and to be clear, I DO want to fix things that we can fix right now. It's just that most of those things CAN'T be fixed because of core Drupal and I'm tired of being publicly shamed for not having them fixed yet when it's out of my control. AND all these deprecations that can't be fixed obscure the very few which CAN be fixed, making it MORE difficult to maintain a contrib module ...

I went through the list in the original post and there are two things that are deprecated but give no indication of which core version they are deprecated in (these were apparently designated as deprecated before core decided to attach a core version number to deprecations).

167x: The $memory_cache parameter was added in Drupal 8.6.x and will be required in 9.0.0. See https://www.drupal.org/node/2973262

Because this feature was added in 8.6.x, we should be able to make this change in the current version of Rules and still support all supported Drupal core verisions. The change notice mentions a number of classes, but Rules doesn't use any of them. So it's not clear to me what code in Rules is triggering this (or maybe it's core code that we're using ...). If anyone knows what needs to be done to fix these, please open a new issue with details ...

114x: \Drupal\user\SharedTempStoreFactory is scheduled for removal in Drupal 9.0.0. Use \Drupal\Core\TempStore\SharedTempStoreFactory instead. See https://www.drupal.org/node/2935639.
114x: \Drupal\user\SharedTempStore is scheduled for removal in Drupal 9.0.0. Use \Drupal\Core\TempStore\SharedTempStore instead. See https://www.drupal.org/node/2935639.

The deprecation notices don't mention it, but looking at the change notices it seems this change was made in core 8.5.x. So we should be able to fix this in the current version of Rules. I have opened a separate issue for this (see #3089549: Fix TempStore deprecations) and I will be posting a patch there shortly.

Again, I would like to fix all of these deprecations, it's just that core doesn't give contrib modules the tools to do this, as explained previously.

Note that once #3089549: Fix TempStore deprecations goes in you'll have to change the deprecations limit again, so maybe we should leave this open until that is committed ...

I am also a volunteer doing this in my spare time and I will gladly help where I can

I totally appreciate that - you're one of the few who helps out in any way with Rules. Rules is used on >25% of all Drupal sites, but pretty much no-one out of that group of 300,000 contributes to Rules. So the fact that you do anything at all makes you an exceptional case, and you've certainly done more than that! Thank you.

I absolutely did not intend to do any public shaming

I apologize if this came across as critical of you. It was not - it was directed mainly towards core Drupal and the maintainers of core Drupal who think they are doing good by calling out contributed project which are not "D9 ready" - yet at the same time Drupal core does not ALLOW contributed modules to be D9 ready . There is currently no way for a module to support both D9 and D8.7 or D8.6 (both of which are technically "supported" D8 versions) either through one branch or multiple branches. There are many features of project pages and there are many blog (etc.) posts which tout D9 compatibility and imply that module which aren't D9-compatible are either unsupported or mis-managed or poorly-managed, but for a non-trivial module like Rules it's literally impossible to be D9 compatible and D8.7 compatible.

Again, that wasn't directed at you.

Do you need me to try any further investigations into 167x: The $memory_cache parameter was added in Drupal 8.6.x and will be required in 9.0.0. See https://www.drupal.org/node/2973262 or did you exhaust the trace?

Yes please - It's not clear to me why we are getting that deprecation error. If you know why this is happening I would like to know! Since D8.6 is the lowest-supported version of Drupal core, we should be able to fix this without breaking any supported version.

I'm going to leave this open so that we can change the deprecation count whenever necessary ...

I opened #3092084: Add $memory_cache parameter to ReactionRuleStorage for that one. I posted a patch that should fix it. Can you test?

Per a Slack discussion with Gábor Hojtsy regarding usage of D9 tags (Drupal 9, Drupal 9 compatibility, Drupal 9 readiness, etc.), "Drupal 9 compatibility" should be used for contributed projects that need updating and "Drupal 9" was the old tag for D8 issues before the D9 branch was ready. Doing tag cleanup here based on that discussion.

I think you posted to the wrong issue - this issue never had any sort of D9 tag, and is just about managing the deprecations messages for things we CAN'T fix at this time.

If you read my posts above, I'm sure you'll understand why I don't want Rules identified with any sort of D9 tag before core Drupal provides the tools to enable non-trivial contributed modules like this to be compatible with both D8 and D9. The whole point of this issue is that we have 10,000 deprecations that CAN'T be fixed until Drupal 9.0 is released.

Thanks for the clarification. I scanned the comments yesterday and there was a discussion about fixing deprecation issues so that's why I tagged it. If fixing this issue isn't needed for D9 support, then I see why you untagged it.

#3030291: ConfigurablePluginInterface is deprecated in core 8.7.x has been committed.

@jonathan1055: Can you run this again with the patch from #3030295: 'context' deprecated in Rules @Condition annotation to see if that patch solved all the 'context' key issues? That should take it down by more than 6000 and leave us only with the EntityContextDefinition problem.

I couldn't find anything I missed in #3030295: 'context' deprecated in Rules @Condition annotation, so my guess is that these addition "context" keys are coming from our Event plugins, which don't use annotation but rather .yml files for discovery. Thus, I think we need to change the "context" key in our *.rules.events.yml files and Event plugin derivers. I will work on that.

I patched the events and combined that with the previous patch. Can you try again and see if the patch in #3030295-15: 'context' deprecated in Rules @Condition annotation takes it to zero now?

Why doesn't the EntityManager deprecation issue show up in the deprecations list? #3045738: Convert entity manager service usage to split up services ( Part 2 ) when Drupal 8.8 becomes the lowest supported version

This is another thing we can't get rid of until D8.8 is the lowest-supported version - see the test output in that issue where it fails miserably for D8.7 because core 8.7 still uses EntityManager.

Committed #27.

Done.

Added #3137977: Replace assertInternalType() calls with dedicated methods when Drupal 8.8 becomes the lowest supported version

Do we even need the .gitignore? I thought best practice was to not have a .gitignore in contrib projects.

Rules 8.x-3.0-alpha6 has been released, so we can now finish off these deprecations.

@jonathan1055: I guess #38 slipped off my radar - is it ready to go now or does it need to be re-rolled?

Committed #40.

This is a pretty terrible solution but it works locally so I'm curious to see whether DrupalCI will like it.

@jonathan1055: Can you check the deprecations with this patch? It fixes them for me ...

Let me repeat, terrible solution, but if it allows us to be D9 compatible then we can add this as a hack to avoid the regression in core while we work on getting core fixed.

#3161582: EntityContextDefinition breaks the context system

@jonathan1055: Now that #3161582: EntityContextDefinition breaks the context system is committed, can you update the issue summary? I want to keep this issue open because Drupal core 9.1.x is now deprecating other things, such as #3153803: [Symfony 5] Update EventDispatcher::dispatch() to make it forward-compatible with Symfony 5 which we need to track. I imagine this will be an on-going process as core is continuously evolving - we will always need to cope with supporting the currently-supported versions of Drupal core as well as the newly-emerging version of Drupal core.

A new D9.1 issue.

Can we sponsor Rules on Drupal 9 in any way?! Please

@kopeboy: Thank you for asking.

Speaking for myself, my biggest constraint is time. So what I need most is more people working on Rules - helping to write documentation and create examples, helping to code - specifically finishing some missing features - and helping to answer posts in the issue queue, including testing and reviewing submitted patches. These are the things that will speed development. If you have some specific areas of interest let me know and I can give you a list of things that I think have the most return for the least effort, or I can give you a list of some of the hardest problems if that's more your style.

Let's close this, since it's really all about the D8 -> D9 transition.

Let's start fresh with a new meta for the D9 -> D10 transitions.

I'm not a developer so I guess I can help with testing and documentation.
Not much I can document until components can't be used with reaction rules from the UI, so please point me to some new developments I can test from a site builder perspective