4.0.1 creates an unsupported module warning on 9.4.x

I have that same issue, and the problem I guess is that the 4.0.x branch of ctools was released as stable (had a complete version nr) even though it's actually still experimental. I have a feeling the Drupal update system somehow got mixed up by later attempts to fix this. The release should have been an 4.0.x-alpha/-beta release from the start, which probably would have avoided the issues. Don't know if that was a mistake that can't be fixed once the release was made...

However, for your situation I think you have a few options, assuming you're running pathauto 1.11:

1. Downgrade ctools to 3.11 by explicitly declaring a dependency on it in your own project composer.json (if you're using a composer-based workflow). If pathauto is the only module that requires ctools, then this should be safe since pathauto itself does not actually do anything with ctools anymore (as per their release notes).
2. Uninstall ctools completely as per the instructions pathauto gives: https://www.drupal.org/project/pathauto/releases/8.x-1.11. Again, should be safe to do if pathauto is the only module requiring ctools.

Pathauto should not have any real dependency on ctools anymore since the 1.11 release, so either option should be fine. Pathauto decided to leave the dependency as a very relaxed '*', meaning any version is supported, instead of removing the dependency completely. Which creates a bit of confusion IMO, but it is what it is...

I would state that it would probably be best to be releasing the 4.x releases, if the branch is not marked as supported, with some sort of non-production modifier like alpha or beta. That would prevent most Composer instances from updating to it if people are using "prefer-stable" like they should be. I would recommend unpublishing the existing official 4.x releases once that's done.

AFAIK it's against policy to unpublish any release, it will break composer sites as they will not be able to fetch that release anymore. Even projects/releases that are unlisted for security reasons AFAIK remain installable with composer AFAIK

My recommendation would honestly just be to deal with the fact that 4.x is now out there and switch to that or maybe release identical 3.x and 4.x versions for the time being.

#3299841: ctools 4.0 plan, deprecate 3.x plans to then use 4.1 as a major version drop around context system changes, but that is IMHO invalid anyway as a minor version should not introduce BC breaks, so that should IMHO anyway switch to 5.x.

> Pathauto decided to leave the dependency as a very relaxed '*', meaning any version is supported, instead of removing the dependency completely. Which creates a bit of confusion IMO, but it is what it is...

To be clear, Pathauto never had an explicit dependency on any ctools version, in general contrib projects often don't as the .info.yml syntax doesn't require a version specifier, it is only now explicitly added as a * as it's no longer auto-generated from the .info.yml. Also, the confusion around the ctools 4.x releases really is not our fault.

in my composer.json I have

    "minimum-stability": "dev",
    "prefer-stable": true,

but ctools decided to use 4.0.1 anyway. now I got that unsupported warning in my status report.

Is there any way to change the message that appears in the "Available updates" report to state that the Recommended version is 3.x instead of the same version it complains about being unsupported?

I'm confused as to what I need to do. I have a site running 4.0.1, because that was shown as an available upgrade from the 3.x branch a while back. Now, that release is being shown as unsupported. Is this just to stop new installations of that version. Or are there now previously unknown problems such that I genuinely need to force a downgrade.

If I downgrade, will there be any issues with (a) changes of behaviour, or (b) the site failing, at a later date,to pick up update hook scripts that need running?

Thanks

@JamesOakley
I don't know your site and which modules you are running, but on mine Ctools was only required by pathauto.

I wonder if using composer to explicitly require ctools v. ^3 would solve the problem

Sure, I know how to downgrade to the 3.x releases.

My question is whether to do so.

So, given that 4.0.1 was apparently fine before, what are the risks if I simply "do nothing", and continue to use the release that is now unsupported?

Or, given that downgrading software is often not recommended (the database could be ahead of the codebase, or future upgrades to a higher 3.x version may not trigger the required database upgrades because the installation thinks a higher upgrade has already completed), what are the risks if I downgrade?

As per the release notes of the 4.0.1 version, it is identical to the 3.10 version: https://www.drupal.org/project/ctools/releases/4.0.1

So if you don't mind seeing the "unsupported version" error, I assume there is no harm in leaving it at the 4.0.1 version. But I would in that case still lock the version in composer.json, so that it doesn't accidentally update to 4.0.2 or something in case one is released, since the docs say the 4.x versions are still experimental. However the downside I see of leaving it at 4.0.1 is if the 3.x branch now receives a bunch of updates before an official stable 4.x is released. You wouldn't be able to benefit from those updates.

Having said that, I performed a downgrade from 4.0.1 to 3.11 on the site where I had it running and have not seen any issues. I decided to do it since 3.x is the recommended version to stay on, pathauto was the only module depending on it, and they again state that they're actually not using any code from it at all. There were no database updates, only code updates. Take the usual precautions of course (backups etc), but I'd say it's fairly safe to downgrade in this case.

I did a general upgrade of Drupal 9 modules on August 6th. I noticed something about ctools 4.0 being available but decided to ignore it - ctools upgraded anyway.

The "Not supported!" error started appearing on August 12th. Running
composer require 'drupal/ctools:^3.11'
downgraded ctools to 3.11.0. The Status Report indicated a pending update for ctools ("Invalidate the service container to force EntityBundleConstriant is Removed.") which ran successfully. So far, no issues.

I noticed that ctools 4.0.1 is still being offered:

composer outdated "drupal/*"
...
drupal/ctools 3.11.0 4.0.1 Provides a number of utility and helper APIs for Drupal de...

Due to how composer works, I'm tending to agree with Berdir here -- we will tag releases for the 4.x branch which will match the 3.x branch for compatibility sake. Any major changes will occur in the 5.x branch instead of the 4.1.x branch because semantic versioning will automatically update people, which will break things.

But as this issue has evolved, it seems like moving the needle forward is probably advised. This means:
1) Re-marking 4.x releaases as supported but NOT recommended. This will allow people to use ctools 4.x if they aren't using anything that depends on the 3.x branch.
2) Mark the 3.x branch as supported AND recommended. No change occurs here.
3) There will be no 4.x branch for development. The 4.x releases will be tagged to the 3.x branch and they will be kept the same.
4) New features will NOT be in the 4.1.x branch, but rather 5.x. to keep semantic versioning happy.

Could you elaborate point 4 please? There already is a 4.x branch, and point 1 says that 4.x releases will be marked recommended. So in what sense will there not be a 4.x branch?

isnt it easier then to just drop the 3.x releases and only do 4.x releases and make a 5.x one with the experimental.

The 4.x branch will be dead because you can tag releases to any branch. Development will occur on the 3.x branch, and will tag releases of 3.x.x and 4.0.x code at the same time from the 3.x branch. Dependent modules can use either the ctools 3.x.x or 4.x.x releases because they're essentially the same.

We cannot drop 3.x releases because many modules and sites depend on that version of ctools. Only when a module or site has manually tested new features should they increment their major version.

> We cannot drop 3.x releases because many modules and sites depend on that version of ctools. Only when a module or site has manually tested new features should they increment their major version.

Well, you could say 3.x is security/critical bugfix only but then also explain that 4.x is essentially the same and does not require more extensive testing (I mean you should always test as the broken 3.x releases proved ;)), don't really see anything wrong with that. But double-tagging works too I suppose.

As mentioned, most sites don't explicitly depend ctools, they depend on pathauto mostly and also page_manager and so on. All those don't have a version specific constraint, that's why people have been so quick to jump to the 4.x versions, as they get updated to it automatically.