Remove requirement for core_version_requirement for module to be compatible with Drupal 9

How would we prevent sites from breaking?

Ignoring the value of core and not requiring core_version_requirement would make possible for the users to try installing a Drupal 7 module (which could happen, for example, because the user thought that a 7.x-1.2 release comes after a 7.0.2 release, and both work on Drupal 9).
Then, not all the Drupal 8 modules can run on Drupal 9; it could be possible to install a Drupal 8 module in a Drupal 9 site (which means that hook_install() doesn't use classes/functions/methods that have been removed from Drupal 9), which then crashes the Drupal 9 site at every page users try to access.

I thought the purpose of core and core_version_requirement was exactly that: Avoiding users install a module release not compatible with the Drupal core running on the site and discover that when they use the site (even if it's a development site).

Should not the condition to accept a module more restrictive? For example, instead of completely ignoring the value of core the code should check its value is 8.
I won't expect a module with a release for Drupal 8.2.x to run without errors on a Drupal 9.2.x site. I don't mean that such modules won't work on a Drupal 9.2.x, but the chances they use a removed class/method/function increases with the release "age" and the complexity of its code.

I can understand that users could need to test a module that isn't declared compatible with Drupal 9, without editing its .info.yml, or they found out a module that isn't declared compatible with Drupal 9 is actually compatible with Drupal 9 and they could need to force Drupal to install it (at their own risk). For those cases, there could be a value in the settings.php file that tells Drupal not to require core_version_requirement.
In this way, not requiring core_version_requirement won't be the default behavior.

(I cannot say such change would be worth the time took to implement it. Probably, this type of change has been already considered and it was discarded for some reason.)

Still, why would code ignore core: 7.x, which would make the module require Drupal 7 as any Drupal 7 module, when the purpose is allowing Drupal 8 modules to run on a Drupal 9 site without altering its .info.yml file?

With the introduction of D8 the promise came that D9 would only remove deprecated code. Contrary to D8 versus D7, which was a complete break. That same promise is with D10 and hopefully with D11. So, a module compatible with D8 is compatible with D9, D10, D11. Usage of deprecated code is considered a bug and should be resolved. So, being compatible doesn't mean there are no bugs. Having bugs doesn't mean a complete break of your site. Several bugs you can live with, some you can't.

The complete opposite suggested here is, instead of waiting for maintainer to give go-ahead, assume it is going to be right. This is the meaning of semantic versioning. Patches have very reduced scope, the fix a bug. Patch releases only contain bug fixes, nothing else. Minor releases are allowed the have bug fixes and new functionality. Major releases are for significant changes allowing something to break when not properly maintained. When not affected by those changes, everything works as always.

See all those bot issues that only need a change in specification, not in code. Yes, there are modules that require more work. So, those should be explicit in saying they are not compatible. So, rather than having to say you are compatible, make it needed to say it is not compatible. When not done by the maintainer file a bug report to say not compatible. Just like what is done now with other bugs,

Still leaves the need for a relaxed endpoint because how do persuade the community to remove core_version_requirement (and core key).

As far as preventing breaking of sites, allowing to use current software is the way to go. Remove unnecessary roadblocks and write more mature software. Software that is more robust, forgiving and provides decent error handling.

This issue is about Drupal 9 that should accept Drupal 8 modules, for which the requested feature is for Drupal 9 to ignore the core value. This means that the requested feature would make Drupal 9 accept a line like core: 7.x (which doesn't make the module a Drupal 7 module) or core: 10.x.

The purpose of the feature request is accepting Drupal 8 modules that hasn't been changed after core_version_requirement was introduced (and made a required key), or they have been changed but the core_version_requirement line was not added (perhaps due to an oversight). Drupal 8.x modules use core: 8.x. Why should Drupal 9 accept every value for core (which is essentially what ignore core means) instead of accepting modules for which one of the following conditions is true for their .info.yml file?

• core_version_requirement isn't used, but core it is, and its value is 8.x
• core_version_requirement is used and core isn't used; the core_version_requirement value doesn't exclude the Drupal version used from the site
• core_version_requirement and core are both used; the core_version_requirement value doesn't exclude the Drupal version used from the site

I wouldn't say that a module written for Drupal 8.2.x is compatible with Drupal 9. The differences between a Drupal 8.2.x module and a Drupal 9.2.x module are certainly less than the differences between a Drupal 6.x module and a Drupal 7.x module (or a between a Drupal 7.x module and a Drupal 8.x module), but if a Drupal 8.x module makes a Drupal 9.x site crash, I wouldn't call it compatible with Drupal 9.

Again, this issue is a feature request for a 180degree change in policy about declaring compatibility. The old way is requiring to specify core key, superseded in 8.7.7 by introducing key core_version_requirement. The preferred key for the future and still required as of D9. As of D9 the core key no longer supported. The feature request here is to remove the requirement. No longer the key is a requirement. When available it is respected. When not available it is considered compatible. Note that it is not limited to D9, expected for D10 and higher as long as the policy doesn't change recarding Drupal Core.

No, this is not about ignoring the core key. It is not even giving a different meaning to that key. D9 only tolerates the core key for 8.x., but requires a core_version_requirement set as 9 constraint. This issue is about removing the requirement. There is already a module that ignores it. Feel free not to use that module.

Again, the purpose of this feature is to remove the requirement for a core_version_requirement key. Rather than insisting the compatibility to be specified, assume compatible when not specified. Specify when it is not a matter of yes or no. Provide the version constraint specifying what it is compatible with, assume compatible when not specified.

Don't think it is possible to declare something only compatible with 8.2 with core_version_requirement. But, it is for 8.8, so this feature request is not going to change that as it will respect that core_version_requirement.
To be honest, I would recommend against modules with such poor specifications.

@mmjvb The IS is clear about that.

Ignore the "core" attribute from info.yml files completely, including when running tests.

If the core_version_requirement line is not present in a project, assume it is compatible with the current core version.

That means accepting a module whose .info.yml file doesn't contain any core or core_version_requirement value, or only a core value which is totally wrong. It's different from accepting a Drupal 8 module that hasn't been updated to include a core_version_requirement value.

Indeed, that is in the IS. Not sure what was meant with that because I thought D9 was already doing that. Turns out is checks that core key. Also in combination with core_version_requirement.
Again, this feature request is about no longer require the core_version_requirement. Currently it is required and checked against an optional core key. When provided that can remain as is. When no core_version_requirement provided then assume valid for the version of Drupal running. Which is ignoring core key. Who cares if it is not 8.x.

That makes it very easy for people to use them. Just remove those keys when provided. Even the relaxed endpoint could do that.

Obviously, the 8 endpoint needs to advertise them.

Who cares if it is not 8.x.

Given that it's from Drupal 6 that modules need to put in their .info file the Drupal version for which they have been written, I would say there is somebody who cares about the Drupal version a module declares to be compatible with.
It has been decided that avoiding a user would try to install a module that isn't for the Drupal version the site is running was important. Drupal 9 doesn't change anything, as a module written for Drupal 8 is still not compatible with Drupal 9, in the same way a Drupal 4.7 module isn't compatible with Drupal 6, or a Drupal 6 module isn't compatible with Drupal 7.

Sounds like you just don't want to understand the issue. A module for D8 is compatible with D9 and D10. Deprecations not solved are just bugs like any other bug.

You may have noticed D8 and later can't deal with modules before D8.

And YES, D8,D9 and D10 did change what is going on. Sounds like you live in the past!

Let's try to keep this discussion productive. Doesn't help, if we start taking this personally ;).

It has been decided that avoiding a user would try to install a module that isn't for the Drupal version the site is running was important.

That is not a reason to reconsider that decision, though. Nothing is set in stone. While it is a fundamental change of policy and it surely is controversial, as we can see from this very issue, I think Damien and others have brought forward valid reasons why this decision might need to be reconsidered.

Personally, I wouldn't mind, if this requirement was dropped, if we tried to implement that "feature" in such a way, that users would still be sufficiently warned, that a module might not be compatible or even break their site. The important thing would be that users would not be blocked from upgrading to a version with security support by those modules, when they somehow come to the conclusion that a module is actually compatible, even if it doesn't declare that compatibility.

I think it would be best to focus our energy in this discussion toward the best way to implement something like this, maybe even find some kind of compromise between the different opinions, rather than just reiterating the same arguments over and over. Yes, this is a fundamental change and it is controversial, that's already been acknowledged by the reporter in the issue summary, but let's focus our discussion on what an actual implementation would look like or how the concerns voiced by the users opposing this change could be mitigated.

Drupal 9 doesn't change anything, as a module written for Drupal 8 is still not compatible with Drupal 9, in the same way a Drupal 4.7 module isn't compatible with Drupal 6, or a Drupal 6 module isn't compatible with Drupal 7.

I'm sorry to say so, but frankly, I don't think this is true. Since Drupal 9 was really built inside Drupal 8 and the 9 branch "just" removed a few deprecated APIs, the majority of Drupal 8 modules are actually compatible with Drupal 9 without any changes except for the version requirement or with just a very simple patch and I guess the same would be true again for the migration from Drupal 9 to Drupal 10. This is backed up by statistics Aquia is generating regularly. So I don't think you could compare that with an upgrade from Drupal 4 to Drupal 6, Drupal 6 to Drupal 7 or Drupal 7 to Drupal 8/9. The fact, that a module declares compatibility with Drupal 8 doesn't really say anything about whether it is also compatible with Drupal 9.

Sounds like you just don't want to understand the issue. A module for D8 is compatible with D9 and D10. Deprecations not solved are just bugs like any other bug.

No, there isn't a bug if the module is correctly using the public API the Drupal version with which it declares to be compatible has. Drupal 9 is still a different version because it has different requirements.

And YES, D8,D9 and D10 did change what is going on.

Drupal 9 make easier to migrate from a Drupal 8 site, but it doesn't allow you to use every Drupal 8 module, including the ones written for Drupal 8.0.x. That has never been a feature Drupal 9 was supposed to have.

I've followed this discussion for a few days. And I agree with @apaderno.

"core_version_requirement" is a guard between D8 and D9, which ensures that whatever model will be used for D9, it must prop itself up according to D9's policy.

This is a key that indicates that D9 is an upgrade to D8.

Drupal 9 is Drupal 9 because it's not backward compatible with Drupal 8; that means that Drupal 9 isn't compatible with a Drupal 8 module, and vice versa. That isn't different from code that uses a class/method/function removed from PHP 8. It isn't said to be compatible with PHP 8; eventually, it could be said to be easily made compatible with PHP 8.

Since what this feature request wants to achieve is allowing users to install a Drupal 8 module in a Drupal 9 site, I could find acceptable if Drupal would check the value of a setting added in the settings.php file, similarly to what Drupal core does with $settings['update_free_access'] for a different purpose. When that setting's value is TRUE, Drupal would also accept modules not containing a core_version_requirement value but containing core: 8.x in their .info.yml file; when their .info.yml files contain a core_version_requirement value, Drupal should use that value and show an error if that value doesn't include the current Drupal core version; when neither core nor core_version_requirement is present, Drupal should show an error.

In this way, users are free to install a Drupal 8 module in Drupal 9, whenever they want to do so because they know that Drupal 8 module doesn't break their Drupal 9 site or they want to test a Drupal 8 module on a Drupal 9 site without editing any file. Still, Drupal 9 won't accept Drupal 8 modules by default. It won't also accept modules with an .info.yml file missing both the core and the core_version_requirement values, but since a Drupal 8 module is supposed to have one or the other value, in its .info.yml file, that isn't a problem.

The proposal in #20 to allow ignoring core_version_requirement via settings.php is interesting, if it also triggered a warning on the status report that you might be running deprecated/untested code. I'm not even sure we need to check core: 8.x as .info.yml files were only introduced in 8.0, so there is no possibility of someone trying to run a Drupal 7 module on Drupal 9 if this was introduced.

@longwave Drupal 8.1.x checks the value of core, for example in update_check_incompatibility() and ModulesListForm::buildRow(). (The value used for the comparison is Drupal::CORE_COMPATIBILITY.)

The function using the following code is update_check_incompatibility(), for which returning TRUE means there is incompatibility.

  if (!isset($file) || !isset($file->info['core']) || $file->info['core'] != \Drupal::CORE_COMPATIBILITY || version_compare(phpversion(), $file->info['php']) < 0) {
    return TRUE;
  }

This is the code used in ModulesListForm::buildRow().

  // Check the core compatibility.
  if ($module->info['core'] != \Drupal::CORE_COMPATIBILITY) {
    $compatible = FALSE;
    $reasons[] = $this
      ->t('This version is not compatible with Drupal @core_version and should be replaced.', array(
      '@core_version' => \Drupal::CORE_COMPATIBILITY,
    ));
  }

Again, there is already https://www.drupal.org/project/backward_compatibility which ignores compatibility.

Contrary to this proposal, it ignores whatever is specified. This proposal is about assuming compatibility when not specified. Specify when not compatible. Remove specification when assuming compatible.

When it needs to be configurable, I would suggest to make it configurable per module.

Agree that this not the correct category, unfortunately it is considered the best fit for a refactor request, as support requests are not allowed for core.

To prevent future contrib module upgrade bottle necks going from D9>D10, D10>D11, etc. yet setting some limits, perhaps recommending defining a minimum and maximum version could be considered? That way contrib modules can be easily installed and worked on in the next official major release while it's underway, but not yet released.

Maybe something like @japerry suggested in Navigating core_version_requirement?

What should core_version_requirement look like?

My personal preference is to work with the next ‘beta’ of a major version. That allows developers to immediately work with a module, but doesn’t allow it to automatically work with the next stable release:
[...]
If your module supports Drupal 9 and 10:
core_version_requirement: >=9.2 <11.0.0-stable

This is also the proposed solution in #3267143: Add a composer plugin that supports 'composer require-lenient' to support major version transitions, though that issue only suggests setting a minimum.

Updated the issue summary: The core attribute is already deprecated, and has been ignored since Drupal 8.
Fixed formatting and a typo.

Fixed more formatting in issue summary.

The proposed resolution is to make a project core version agnostic if the maintainer removes the core_version_requirement setting from ".info.yml".

The proposed resolution is equivalent to what the maintainer will get if they use the following unbounded core version constraint:

core_version_requirement: >=9.0

I.e.: There is not need to change core to have this behaviour.

Using an unbounded version constraint is one of the possible resolutions under discussion in #3267143: Add a composer plugin that supports 'composer require-lenient' to support major version transitions.

I think this issue should be closed as a duplicate.

Thank you for bringing my attention to this issue.

I think unbounded version compatibility will be a far larger problem moving forward than the current situation.

Yes, a 10.5 module is almost certainly compatible with 11.0, but likely won't be with 12 and certainly not 13 which these unbounded requirement requests don't seem to take into consideration.

If a maintainer doesn't step up to merge the automated fixes I think that's a great signal to the community that a new maintainer is needed for that module. Without that there is no signaling to less experienced site maintainers.

Comment 30 does provide an equivalent workaround that I'm starting to see in contrib even if I think it's a mistake.

For that reason and the related issue https://www.drupal.org/project/drupal/issues/3387322 think this should be closed as a duplicate since the related issue would complete the puzzle of the request here.

I think @longwave's and@cmlara's proposal to add a status report error along with the alleviates some of my concern since it's two explicit steps to get this.

I'll leave this open for a bit in case I missed an edge case, but I think this request is now a duplicate.

Edit to add I think this issue actually provides a great way to illustrate my concerns with this since it's been so long.

Let's find some old drupal 8 modules that haven't been updated with the core version requirement key.

Add the key with a * and install it on Drupal 11, this will test the situation this issue is trying to enable, I'd be curious to see how many will work if any.

I think unbounded version compatibility will be a far larger problem moving forward than the current situation.

Were not trying to make it unbound, this issue is part moving the bounding to composer to match the rest of the PHP Ecosystem (removing likely unneeded Drupalisms code)

I'll leave this open for a bit in case I missed an edge case, but I think this request is now a duplicate

One allows for an override of the feature code (adding more code to maintain) while this issue removes the entire feature code from Core (generally less code = better from a maintenance standpoint).

Comment 30 does provide an equivalent workaround that I'm starting to see in contrib even if I think it's a mistake.

This is true, from a contrib standpoint, however if maintainers are going to do this I would suggest it is time to remove the code.

core_version_requirement still allows an incompatible module to be executed as it is IIRC only checked when a module is requested to install, and when update.php. The former never occurs on a running production site, and the latter is already often missed, if anything this existing code makes it more likely a site owner may skip database updates to run very_important_module (especially since failure to run database updates isn't usually immediately apparent as a fault).

Add the key with a * and install it on Drupal 11, this will test the situation this issue is trying to enable, I'd be curious to see how many will work if any.

I would like to, however I unfortunately can't download the module to make this test, composer constraints already protected me from breaking my site.

 composer require drupal/colorbox:^1
./composer.json has been updated
Running composer update drupal/colorbox
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires drupal/colorbox ^1 -> satisfiable by drupal/colorbox[1.0.0, ..., 1.10.0].
    - drupal/colorbox[1.5.0, ..., 1.10.0] require drupal/core ^8.8 || ^9 -> found drupal/core[8.8.0, ..., 8.9.20, 9.0.0, ..., 9.5.11] but the package is fixed to 10.5.6 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
    - drupal/colorbox[1.0.0, ..., 1.4.0] require drupal/core ^8 -> found drupal/core[8.0.0, ..., 8.9.20] but the package is fixed to 10.5.6 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

Installation failed, reverting ./composer.json and ./composer.lock to their original content.

In fairness this release was compatible with ^9 as well, however the point still stands, you can't download old code without concerted efforts to override the system (claim running old core version, lenient plugin against that specific module, etc).

Note: I'm ignoring manually obtained tarballs which the Core team deprecated when they removed the ability to upload updates through the UI in favor of a composer-only managed install. If this went D12+ (which is the next major where this is useful) tarballs are essentially irrelevant to protect against as they are unsupported.

What you're talking about seems to be the issue you related in 32, but it's not what i understand this issue to be asking for.

I think it we resolve 32 separately it also precludes this, but I don't think this should be done separately from either related issue.

, but it's not what i understand this issue to be asking for.

I indeed forgot about the second part of this issue If the core_version_requirement line is present in a project, process it as normal. (should follow my own advice and re-read the full issue thread before commenting on issues I've been following for years).

#3005229: Provide optional support for using composer.json for dependency metadata would have core still aware the module is or is not not compatible by parsing a secondary data source.
#3387322: Allow contrib extensions to be installed by Drupal when core branch is 11.x/main would have core aware while supporting only a single data source and adding a settings.php option that site owners can disable protection.
This issue (currently) would have core assume if the module is on disk it is compatible unless it indicates otherwise.

My desire is that Core can become 100% ignorant of the supported version of a module, it doesn't need to know because external systems already control that aspect.

My post in #35 is indeed mistaken that this wouldn't immediately remove code from core unless we change the proposed resolution to remove the second condition (retain processing of core_version_requirement. I would suggest as part of the remaining task of reaching an agreement we strike said provision, thus allowing this issue to close the other two issues and core to accept that if its on disk its compatible.