Fatal error: trait not found, due to core not yet having been updated to the latest security release

Is needed to upgrade Drupal Core to use the version 8.x-2.3. I created a patch to ensure this requirement.

I think that the module page must warning users to ensure all the people use the correct version of the Drupal Core and JSONAPI module.

JSON:API 2.x still supports Drupal 8.5.

The file:

src/Normalizer/FieldItemNormalizer.php

Uses the trait:

Drupal\serialization\Normalizer\SerializedColumnNormalizerTrait;

The trait is used on FieldItemNormalizer sinze JSONAPI 8.x-2.3

https://cgit.drupalcode.org/jsonapi/commit/src/Normalizer/FieldItemNorma...

This trait is introduced in drupal 8.6.10:

https://cgit.drupalcode.org/drupal/commit/core/modules/serialization/src...

The version 2.x (>2.3) now has a dependency of Drupal >= 8.6.10. I think this is a fact.

The version 2.x (>2.3) now has a dependency of Drupal >= 8.6.10. I think this is a fact.

It's a bit more subtle than that :)

JSON:API 8.x-2.x supports Drupal core 8.5, 8.6 and 8.7. For Drupal 8.5, it requires Drupal 8.5.11. For Drupal 8.6, it requires Drupal 8.6.10 (as you say). For Drupal 8.7, it requires the latest version (we "chase HEAD" as they say).

If you look at the commit history of jsonapi.info.yml, you'll see we bumped the requirement from 8.5.4 to 8.5.11 — indeed to require the latest security release.

Unfortunately, Drupal's .info.yml files only allow us to express a single minimum version. Which means this doesn't work as nicely when a module supports multiple branches, like JSON:API does.

That's why you're both right! 👍 But this unfortunately means we cannot commit #3, since it'd signal that JSON:API 2.x no longer supports Drupal 8.5.x.

I'm talking to people in Drupal Slack to figure out if there's an issue for this, because this is not going to be the last time a contrib module runs into this problem.

If there are a diversification for Core versions a module need an stable release for each diversification. I know that is not easy maintain three releases of a module.

Branch 2.x -> Core >= 8.5.11
Branch 3.x -> Core >= 8.6.10

Edit:
In this case i think that the higher version of core must be used as a dependency, not an older and deprecated version in the next future.

If there are a diversification for Core versions a module need an stable release for each diversification. I know that is not easy maintain three releases of a module.

That's not correct. There's nothing wrong with one module supporting multiple branches. This is purely a limitation in *.info.yml files' infrastructure. A limitation that can easily be fixed.

In this case i think that the higher version of core must be used as a dependency, not an older and deprecated version in the next future.

I agree with this sentiment, but it'd mean that it's impossible for a site on the previous minor to install this update.

Then advise it in the module page.

You must have the latest versions of 8.5 and 8.6 drupal core to have this module.

Yesterday I updated this module before the Drupal core upgrade and I spent some time to determine the problem. If the module only have the requirement of 8.5 core version my first approach was that the last update of JSONAPI module is corrupted and is not valid.

Think about it. I won't the issue credit, please not think that i want that you merge my patch only for that, only want to prevent other users to spent unnecesary time.

I completely understand where you're coming from. I do. I hate that Drupal isn't more precise, more strict and more helpful in its dependency handling.

That's why I asked relevant people on Drupal Slack. I want to solve this at the root. I want to be able to do something like this:

-  - drupal:system (>=8.5.11)
+  - drupal:system (>=8.5.11, >=8.6.10)

That'd solve it. Stay tuned!

Then advise it in the module page.

But people updating their site using composer won't ever see that.

I think I just found one related issue: #2807145. Left a comment at #2807145-28: [policy, no patch] Allow contrib projects to specify multiple major core branches.

There are the solution.

Thanks.

After any upgrade of a module or a drupal core a user must run the update.php script. This script must advise them, if not is a bug of the core of Drupal.

For composer I think that the composer.json of the module can stablish a dependency of core version. Now i have not time to write it but it must be possible.

Re: #10:

A limitation that can easily be fixed.

Hah! ;) Easy. Sure.

So to resume:
a) IF people install jsonapi on a pre-security-release drupal installation,
* they get this error message
* feed it to google and get here
* learn that they must update core
b) to correctly specify the dependency in .info.yml we need to land #2807145: [policy, no patch] Allow contrib projects to specify multiple major core branches - until that people on not-security-updated drupals will be able to run into this issue
c) if i get it right, we might for the time being add the dependency mentioned in #12 to the composer.json - patch appreciated, so NW

(@wim, tentatively unassigning you, feel free to correct me.)

#16 is accurate. :)

By the time the blocker is fixed, this module will be in core 🤞or this will have long since become irrelevant.