Testing with Drupal 8

what do you think about dropping D8 support? D8 isn't supported by core, if someone is still using D8 think that would be on them. They could use an older version of this module but don't think it's contribs job to keep D8 alive.

Yes you are probably right. But please can we wait until the 2.0.0 release is made, so that we have a full 2.x release which is compatible with D8. Then if things need to change and we are forced to move on from D8-compatible source code, we can state this on the project page, and users will have to stick on 2.0.0 while they are still migrating from D8.

Just started a 3.0.x branch that will have D10 and D11 support only. Believe this one just got lost with time so going to close out for now.

What is your plan for releasing a full 2.0?
Currently 2.0.0-beta supports ^8.7.7 || ^9 || ^10
If 3.0 is going to be for D10 and D11 only, then can the 2.x series remain compatible with 8/9/10 as currently?

Sure if you want. Since D8 and D9 are unsupported have been putting less focus into those.

2.x now runs pipelines on D10 and D9. I need to find out how compatible 2.x is with Drupal 8 before we release 2.0.0. If it is no longer compatible then the composer.json needs to be updated. We've not tested on D8 for a while.

The 2.x codebase is no longer compatible with Drupal 8. See
https://git.drupalcode.org/project/scheduler_content_moderation_integrat...

We have introduced features such as the trailing comma in function definitions, for example in #3444137: Fix new PHPCS standard for multi-line function definitions → but due to not testing with D8 at the time we did not realise this syntax is incompatible with PHP7.4 (the highest PHP version for D8). That change could be reversed, and the phpcs messages ignored using phpcs:ignore Drupal.Functions.MultiLineFunctionDeclaration.MissingTrailingComma like I did on 8.x-1.x.

I will see if that is the only problem, then we can make a decision whether to keep 2.x available on D8, or chnage the composer.json condition before 2.0.0 release.

There are lots of other things that cause the tests to fail
https://git.drupalcode.org/project/scheduler_content_moderation_integrat...

We could find ways to get round this, but it would be tedoius and time-consuming. I think we should just drop Drupal 8 support from the 2.x composer.json and .info file, before releasing 2.0.0

Undo the above work, and drop Drupal 8 support.

LGTM

Merged.

Even though we are not testing 2.x with Drupal 11 we do need to be able to test it at PHP8.4. This can be done with the variable, and will need the core version set to Drupal 10 not 11.

Done.

The multiple deprecation warnings Implicitly marking parameter as nullable is deprecated, the explicit nullable type must be used instead in the phpunit tests are for 3rd-party modules such as Address, Entity and Commerce that we use in testing. The log is very long but I could not see any deprecations for SCMI functions.

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