Correct core_version_requirement

Please review MR.

Hi that is correct module is working good.

Change makes sense and following drupal phpcs

Actually, I'm not sure about version compatibility. I think it should work for all D8 versions, but testing is available only for 8.9, and we don't get any feedback from users.

The word "only" in the OP is not mine, and as long as we don't have evidence to the contrary, I'd leave it at ^8.

Drupal 8.0-8.7 does not understand the core_version_requirement key, so it simply will refuse to install if you try to install it any version prior to Drupal 8.8.

The reason you don't get any feedback from users about this is probably because almost nobody uses versions of Drupal 8 prior to version 8.9 anymore. Those versions have a lot of highly critical vulnerabilities and if you use them, you are putting your at risk.

I am pretty sure that the the latest version of this project cannot be installed on versions 8.0 - 8.7 because they don't know about the core_version_requirement key.

However, I've so far been unable to install Drupal core version 8.7.14 to produce the requested evidence for this (see this forum post → for reference).

If you want to claim fictitious compatibility in the project's acl.info.yml – well, I guess that very few people is impacted by it, so I won't use much more energy on it.

almost nobody uses versions of Drupal 8 prior to version 8.9 anymore.

As of August 27, 2023, https://www.drupal.org/project/usage/drupal → shows about 40'000 sites using 8.x (x < 9) and 53'000 sites using 10.x.

I feel fine about not artificially blocking those 40'000 sites.

I am pretty sure that the the latest stable version of this project cannot be installed on core versions 8.0 - 8.7 because these versions of core don't know about the core_version_requirement key.

Choking on an unexpected key would not be very elegant...

Core prior to version 8.8 will not be choking on an unexpected key. It will choke on being unable to see that the module is compatible with version 8 of core

Well, it still chokes ☹️.

I've now finally managed to set up a Drupal test site that runs core version 8.7.0.

Downloading ACL version 8.x-1.0 and placing it inside the code base results in a WSOD if the administer tries to visit the "Extend" page, even without installing it (and of course, because this crashes the site), there is no way of installing it. I've updated the issue summary with these findings.

The reason none of the users potentially affected by this has filed a bug report against 8.x-1.x-dev is probably because anyone still running an insecure and unsupported Drupal version 8.x-7.x (or older), don't upgrade anything until something breaks. They will of course not be blocked until they try to upgrade to ACL version 8.x-1.0 – without first upgrading core to at least version 8.8.0.

You may feel fine about leaving this core version requirement set to a too optimistic value (and for your users to figure out for themselves why this module breaks their site), but as I said initially: It is better to document the real requirements for installing a specific version of the module.

Setting it back to"Active".

Ok, thank you for the investigation, @gisle.

Can we fix it rather than blocking it?

Yes, it can be fixed. I've updated MR !6 to fix it.

Please see this change record → for background. It says:

core: 8.x can still be used for modules that need to specify core compatibility with version before Drupal 8.7.7.

Personally, I don't think it is a good idea to encourage the contined use of versions of core that no longer have security support. But this is your project, so you set its policies.

Great, thank you, @gisle!

Personally, I don't think it is a good idea to encourage the contined use of versions of core that no longer have security support. But this is your project, so you set its policies.

I'm not encouraging people to stay behind, but I don't want to force them to upgrade either. There can be many reasons for not being able to or not wanting to update/upgrade.

And I'm really sorry if I caused pain with WSODs.

And I'm really sorry if I caused pain with WSODs.

You probably didn't, except me – and I expected that to happen (so no pain).

I don't think anyone that is still running Drupal version 8.x-7.x (or older) would have upgraded this module to version 8.x-1.0, and they probably will not upgrade it to 8.x-1.1 either. But it is nice that it is now technically correct.

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