ctools 4.0 plan, deprecate 3.x

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?

After letting the 3.x and 4.x version bake together for the past year, I think its time we re-evaluate the versioning in ctools goes.

Why are 3.x and 4.x the same?
In the D10 release process, there was a misconception that we needed to make a major version bump to support Drupal 10 and drop Drupal 8. However, by doing this caused a dependency chain issue where downstream modules could not work with Drupal 10 without upgrading ctools as well.

Since there was no other technical reason within ctools, we went back to 3.x as the supported version, and 4.x as 'experimental'

What is the supported version now?
As of May 31 2023, its 3.x -- however, I believe its time we switch supported and recommended, due to how composer grabs latest versions. By making 4.x the recommended version, builds will be inline with what they expect. We will keep making 3.x builds in parallel with 4.x, so dependencies requiring 3.x still work.

Will 4.x ever diverge from 3.x?
No. Any features brought into 4.x will also be brought into 3.x.

What about 4.1.x?
Major changes such as context system changes, will be in 5.x.

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?

Updated the issue summary. Hopefully that makes things more clear:

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.

Updated the parent summary. Basically:

• 8.x-3.x will NOT support Drupal 11
• 4.x will become the base development branch
• 4.1.0 will be Drupal 10 and 11 compatible

4.1.0 is out! with this, 4.0.5 and 8.x-3.15 are the final releases for D10 and below... unless there is a security or other fatal issue found.

All future development should be against 4.1.x.

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.

The 4.0 to 4.1 update is really an incremental one, sorta like 4.0.4 to 4.0.5. But its unfortunate that Drupal core treats minor releases of contrib modules like core, because any old release is instantly 'unsupported', but there is only an alert when its a minor version update. I wasn't going to make a 4.0.5 release, but then noticed that if someone had a blocking issue with 10.3 and was 'pinned' to the 4.0.x releases, we should fix it there so the 3.x/4.0 releases remained D10 compatible.

So if you're on the 4.x releases, updating to 4.1 should be seamless, unless a downstream module pinned to ~4.0.4, which is not a recommended practice.

As for 3.x, it was marked as 'supported' but not recommended to give a little more time for maintainers with downstream modules so they can update their dependencies to 4.x from 3.x. But 3.x is also essentially EOL and will be marked unsupported sometime after D11 comes out.

Automatically closed - issue fixed for 2 weeks with no activity.