Impossible to update some modules via Composer

Question

I've updated a D8 website from 8.7 to 8.8.1 with SSH and composer. For some modules (in SSH 3rd column is marked in yellow) it is not possible to update them. I understand that when they are marked in yellow some dependencies are missing?

The rest of the modules are updated successfully.

Below the list of modules that needs an update (3rd column is marked in yellow):

drupal/blazy         1.0.0-rc5 2.0.0-rc6 Provides basic bLazy integration for lazy loading and multi-serving images.
drupal/file_mdm      1.1.0     2.0.0     Provides a service to manage file metadata.
drupal/file_mdm_exif 1.1.0     2.0.0     Provides a file metadata plugin for EXIF image information.
drupal/file_mdm_font 1.1.0     2.0.0     Provides a file metadata plugin for TTF/OTF/WOFF font information.
drupal/slick         1.2.0     2.0.0     Slick carousel, the last carousel you'll ever need.
drupal/slick_views   1.0.0     2.1.0     Provides Slick carousel integration with Views.

In composer.json: slick and slick_views are added. Other above modules are not located in the composer.json:

{
    "name": "drupal-composer/drupal-project",
    "description": "Project template for Drupal 8 projects with composer",
    "type": "project",
    "license": "GPL-2.0-or-later",
    "authors": [
        {
            "name": "",
            "role": ""
        }
    ],
    "repositories": [
        {
            "type": "composer",
            "url": "https://packages.drupal.org/8"
        }
    ],
    "require": {
        "php": ">=5.6",
        ...,
        "drupal/field_group": "^1.0",
        "drupal/slick": "^1.1",
        "drupal/slick_views": "^1.0"
        ...,
    },
    "require-dev": {
    },
    "conflict": {
        "drupal/drupal": "*"
    },
    "minimum-stability": "dev",
    "prefer-stable": true,
    "config": {
        "sort-packages": true
    },
    "autoload": {
        "classmap": [
            "scripts/composer/ScriptHandler.php"
        ],
        "files": ["load.environment.php"]
    },
    "scripts": {
        "pre-install-cmd": [
            "DrupalProject\\composer\\ScriptHandler::checkComposerVersion"
        ],
        "pre-update-cmd": [
            "DrupalProject\\composer\\ScriptHandler::checkComposerVersion"
        ],
        "post-install-cmd": [
            "DrupalProject\\composer\\ScriptHandler::createRequiredFiles"
        ],
        "post-update-cmd": [
            "DrupalProject\\composer\\ScriptHandler::createRequiredFiles"
        ]
    },
    "extra": {
        "enable-patching": true,
        "composer-exit-on-patch-failure": true,
        "patchLevel": {
            "drupal/core": "-p2"
        },
        "installer-paths": {
            "web/core": ["type:drupal-core"],
            "web/libraries/{$name}": ["type:drupal-library"],
            "web/modules/contrib/{$name}": ["type:drupal-module"],
            "web/profiles/contrib/{$name}": ["type:drupal-profile"],
            "web/themes/contrib/{$name}": ["type:drupal-theme"],
            "drush/Commands/{$name}": ["type:drupal-drush"]
        },
        "drupal-scaffold": {
            "initial": {
                ".editorconfig": "../.editorconfig",
                ".gitattributes": "../.gitattributes"
            }
        },
        "patches": {}
    }
}

With these commands: nothing to install or update

composer update drupal/slick --with-dependencies
composer update drupal/slick

In the backoffice D8 (/admin/modules/update) it reports that field_group needs an major update. That is not reported via SSH:

composer outdated "drupal/*"

I've tried to remove "field_group" to reinstall it:

composer remove drupal/field_group
...
composer require drupal/field_group
...
Using version ^1.0 for drupal/field_group

Why is it not using version: 8.x-3.0-rc2?

I've removed the vendor folder. I've removed the composer.lock file.

What can I do to update the site to have the latest versions applied for the above list of modules? Simply removing and reinstalling is not working.

Answer 1

Major version changes contain breaking/incompatible changes in SemVer / Semantic versioning. If you would update them, it would break modules that depend on the old version. Therefore most projects lock composer entries to one specific major version number. Also doing a default composer require vendor/project - without denoting an explicit version number - will create an entry locked to the current major version number.

The common way for a major version change is to explicitly composer require a new major version, but this usually means manually doing extra upgrade/migration steps outside of composer.