Problem/Motivation

Drupal::CORE_COMPATIBILITY is used in many places throughout to filter on core compatibility. Historically this has all corresponded to project branch and version names with the 8.x- prefix

Now that #2313917: Core version key in module's .info.yml doesn't respect core semantic versioning has been committed projects and specify that they are compatible with multiple versions of core using the core_version_requirement key in info.yml files

Proposed resolution

Completely remove this constant if possible, remove from any many uses as possible if not.

Remaining tasks

Identify all the issues for usages

  1. #3074993: Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates
  2. #3016471: Make localization file download major version agnostic

It may be too late to deprecate this const in 8.x so it might have to wait until 9.x.

User interface changes

There are few places where it is used in message shown to the user. Determine if those message will change or the MAJOR_VERSION.x will be derived from different sources but the message will remain the same.

API changes

TBD

Data model changes

TBD

Release notes snippet

CommentFileSizeAuthor
#16 3085662-16.CORE_COMPATIBILITY.grep_.txt1.18 KBdww

Comments

tedbow created an issue. See original summary.

tedbow’s picture

tedbow
he/him
Primary language English
Location Ithaca, NY, USA
commented
Related issues: +#3016471: Make localization file download major version agnostic
xjm’s picture

xjm
she/her
Primary language English
commented
Title: Remove Drupal:;CORE_COMPATIBILITY because not accurate after multiple core branch compatible modules » Remove Drupal::CORE_COMPATIBILITY because it is not accurate when modules can be compatible with multiple core branches
Status: Active » Postponed
Issue tags: +Drupal 9

 

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

xjm’s picture

xjm
she/her
Primary language English
commented
Version: 8.9.x-dev » 9.1.x-dev

We won't deprecate this constant before 9.1.x.

andypost’s picture

andypost
he/him
Primary language Russian
commented
Status: Postponed » Active
webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

Could we at least make it 9.x then, in lieu of removing it? It would make it easier to write logic to do different things based on the major Drupal version.

berdir’s picture

berdir
Primary language German
Location Switzerland
commented

> Could we at least make it 9.x then, in lieu of removing it? It would make it easier to write logic to do different things based on the major Drupal version.

We've discussed in slack why it won't be renamed, that would break 8.x-x.y branches/releases on D9, it will either go away completely (at least as constant) or be renamed to something else, like LEGACY_COMPATIBILITY or something and remain 8.x forever. And that you should use Drupal::VERSION then instead to check the core version.

Just leaving this here to avoid confusion.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

nedjo’s picture

nedjo
he/him/his
Primary language English
commented

As an interim measure it would be useful to add a comment to the const declaration, perhaps referencing this issue. As is, the line const CORE_COMPATIBILITY = '8.x'; in Drupal 9.x looks like an error.

tedbow’s picture

tedbow
he/him
Primary language English
Location Ithaca, NY, USA
commented

@nedjo I agree this needs comment. Created #3188689: Document why CORE_COMPATIBILITY is still 8.x in higher branches

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

dww’s picture

dww
we/he/they
commented
StatusFileSize
new 3085662-16.CORE_COMPATIBILITY.grep_.txt1.18 KB

+1 to removing this constant. To get the ball rolling, here are all 7 of the occurrences of 'CORE_COMPAT' in 10.1.x branch of core.

dww’s picture

dww
we/he/they
commented

Some initial thoughts on the above list...

  1. core/includes/update.inc:          $ret[$module]['warning'] = '<em>' . $module . '</em> module cannot be updated. It contains an update numbered as ' . \Drupal::CORE_MINIMUM_SCHEMA_VERSION . ' which is reserved for the earliest installation of a module in Drupal ' . \Drupal::CORE_COMPATIBILITY . ', before any updates. In order to update <em>' . $module . '</em> module, you will need to install a version of the module with valid updates.';

    This is fully wrong. 😉 IMHO, it should be using \Drupal::MAJOR_VERSION (see #3134417: Add \Drupal::getMajorVersion()) not always printing '8.x' in this warning message.

    Also, shouldn't this message all be wrapped in t()? 

  2. core/lib/Drupal/Core/Extension/Dependency.php:      $this->constraint = new Constraint($this->constraintString, \Drupal::CORE_COMPATIBILITY);

    This one is more tricky to undo. 

  3. core/lib/Drupal/Core/Extension/ModuleDependencyMessageTrait.php:      $version = str_replace(\Drupal::CORE_COMPATIBILITY . '-', '', $modules[$dependency]->info['version'] ?? '');

    Here we're using it to conditionally strip off any '8.x-' from a contrib module's version string. Perhaps we don't need a constant for this and can hard-code it in here. 

  4. core/lib/Drupal/Component/Version/Constraint.php:   *   Normally this is set to \Drupal::CORE_COMPATIBILITY by the caller.

    This is the bulk of where we need to figure out what we want. 

  5. core/lib/Drupal.php:  const CORE_COMPATIBILITY = '8.x';

    To be removed. 🤞 

  6. core/modules/system/system.install:        $version = str_replace(\Drupal::CORE_COMPATIBILITY . '-', '', $required_file->info['version'] ?? '');

    Same story as ModuleDependencyMessageTrait... only using it to optionally strip '8.x-' from contrib versions.

    Perhaps we want to move some of this stripping logic into core/lib/Drupal/Component/Version somewhere so we can put the hard-coded weirdness in one spot and re-use it anywhere we're converting contrib bespoke version strings for comparisons.

    Or maybe core/lib/Drupal/Core/Extension/ExtensionVersion.php would be better for this... In fact, it's already got a CORE_PREFIX const in there.

dww’s picture

dww
we/he/they
commented
Related issues: +#3093789: system_requirements() strips core compatibility in really fragile and dangerous way when comparing versions

Adding #3093789: system_requirements() strips core compatibility in really fragile and dangerous way when comparing versions as related re: point 6 (and 3) above...

catch’s picture

catch
he/him
Primary language English
commented
Related issues: +#3106712: Decide what to do with Drupal::CORE_MINIMUM_SCHEMA_VERSION and surrounding logic

Adding a related issue for schema version.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.