ctools 4.0 plan, deprecate 3.x

I'm pretty surprised 4.0.0 was unpublished. We have a composer metapackage that requires ctools 4.0.0 and multiple projects depending on that metapackage. Now we can't update the projects to the current version of the metapackage until we downgrade ctools.

- my-org/my-project-metapackage dev-master requires drupal/ctools 4.0.0 -> found drupal/ctools[dev-3.x, dev-4.0.x, dev-4.1.x, 3.0.0-alpha17, ..., 3.x-dev (alias of dev-3.x), 4.0.x-dev (alias of dev-4.0.x), 4.1.x-dev (alias of dev-4.1.x)] but these do not match your constraint and are therefore not installable. Make sure you either fix the constraint or avoid updating this package to keep the one present in the lock file (drupal/ctools[4.0.0]).

Question: if we had installed version 4.0.0, is it safe to downgrade to 8.x-3.10?

Well. Not sure what could have gone wrong, but after downgrading as suggested
composer require drupal/ctools:^3.11

Drupal installation is unreachable.

Ctools module was on latest 4.01 before the 'downgrade' and crash. Any ideas? Can I attach some logs or whatsoever?
T.I.A.

B.T.W. 'crash' means browser keeps trying to load 'something' for ever while blank page shows on ANY URL address for the site, be it public or admin.

UPDATE.
Emptying the cache (I did it straight in SQL queries, truncating 'cache*' tables) did the trick. After that I could run the DB update from URL and everything seems back to normal with the Ctools downgrade applied. Hope it helps.

In case you came here because Ctools is/was a Pathauto dependency, see #3303233: Please pin ctools dependency on 3.x branch.

I don't understand how it was recommended and then we decided not to do it?
Now I have a bunch of projects that swear at this error. How to fix it?

On a site in preprod, I prefer ask before to do a big mistake…

If I understand well, Chaos Tool Suite (ctools) (Non supportée) <--------- it means that I should downgrad the module?
I have now:

cat composer.json | grep ctools
    "drupal/ctools": "^4.0"

Should I just do a: composer require 'drupal/ctools:^3.11'

It's a safe way?

//EDIT: installed version: 4.0.1
Nom système : ctools
Version : 4.0.1
Requis par (required by) :

Chaos Tools Blocks (désactivé)

Hi!

Solved. In my case (Ctools not used by another module (just an old dependancies from pathauto) I just uninstall it with the GUI. Then I have downgrade with a: composer require 'drupal/ctools:^3.11' then reactivate it in GUI.

Thanks to cmlara and dimkritsotakis on slack.

Or a ctools 4.0.2 release that is not broken. Yes we are all well aware by now that the 3.x series is the one to stay with but the 4.x series unfortunately currently exists right now and we should not have to be actively fighting to stop CTools from breaking sites on composer update.

whats the state of the 4.x branch? The module home page still says it's experimental, but also says it works with Drupal 10.

When should users move to the 4.x branch?

Thanks for the details @japerry

Do you suggest D10 users who are on the latest everything remain on the 3 branch here, or should we move to 4?

thanks @japerry. It sounds like those of us on D10+ should use the 4.x branch, and it's just a matter of updating the documentation on the module home page to reflect this.

ctools 4.0.5 has just been released, but is unsupported? Why even make the release?

Would it not be more wise to make the 4.0.x supported, but not recommended? Even the 8.x-3.x branch is currently supported.

Removing the recommended flag would also get people to move from 4.0.x but without the alarm of unsupported. At least then the branch would be deprecated with notice.

@ELC, I share your frustration and have personally disabled emails from the update module in favor of using composer audit to catch more serious security issues. However, I believe this discussion belongs upstream in either the Drupal core queue or the Drupal.org infrastructure queue.

I have had many discussions with them regarding this frustrating scenario (on Slack). It’s technically a security issue since we (maintainers) are no longer supporting that branch. This means a security issue could arise, and we are indicating that we will not address it on that minor release branch. Additionally, this problem is historical as we never used to have semantic versions, which compounds the issue, as do our branch naming conventions and how Drupal.org creates releases.

Alternatively, we could keep it open on this project as you’re suggesting, but this would be like playing whack-a-mole. Other maintainers might do this accidentally or on purpose, and you would end up chasing them around the queue. That’s why I recommend taking this problem upstream.