Will there be a final 8x release containing ^8 || ^9 compatibility?
Current releases prevent update to Drupal 9 (need to uninstall and then reinstall module).

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

_kom__ created an issue. See original summary.

znaeff’s picture

Hello.

We should discuss this among the team.

We will contact you within 2-3 workdays.

Best regards,

Sahana _N’s picture

Status: Active » Needs review
FileSize
330 bytes

Please review the patch.

znaeff’s picture

Thank you for the patch, we will check it.
Best wishes,

_kom__’s picture

Are you still discussing it?

Serge-M’s picture

Thank you for your question.
Due to a high load of the programmer staff we will fix it in the upcoming work week.
Please, wait.

_kom__’s picture

You've promised to apply this simple patch in 3.6 release (months ago).
"Upcoming work week" is gone too.

Serge-M’s picture

I'm sorry we couldn't make it in time.

I've refreshed the task. The programmers should look into it on the nearest Monday.

Please, wait.

_kom__’s picture

Another week is gone and there is no any commit.
Have to return to CAPTCHA protection.

Serge-M’s picture

Hello.

I've asked the programmer staff and they said that this task has a high priority, however, unexpected fixes for other plugins can intervene.

It should be completed on the next work week.

Please, wait.

MattKD’s picture

FileSize
226 bytes

Due to the Drupal.org packaging script, the patch in #3 was not applying cleanly for me.

I have attached an updated patch with fewer lines of context.

znaeff’s picture

Well, thank you. I transfer this to the developer.

znaeff’s picture

Status: Needs review » Fixed

We've released a new version with Drupal 9 support

https://www.drupal.org/project/cleantalk/releases/8.x-4.1

GrahamShepherd’s picture

I tried installing this version with composer:
composer require "drupal/cleantalk:^4.1"
The result appears in Available updates as
"Anti Spam by CleanTalk 8.x-4.1 Up to date"
as one would expect.

However, when I run:
composer outdated "drupal/*"
I get "drupal/cleantalk 4.1.0 9.1.0" showing as a required update.

Things don't look quite right.

znaeff’s picture

Thank you. We will check this within 1-2 business days.

GrahamShepherd’s picture

Status: Fixed » Needs work
_kom__’s picture

I do not see this message on Drupal core 8.9.7.
"Composer outdated" shows all versions newer than installed. So 9.1.0 will always appear as available.

_kom__’s picture

drupal/cleantalk 4.1.0 9.1.0 Cloud antispam solution without captcha.
drupal/core 8.9.7 9.0.7 Drupal is an open source content management ...
drupal/core-composer-scaffold 8.9.7 9.0.7 A flexible Composer project scaffold builder.
drupal/leaflet 1.45.0 2.1.2 Integration with the Leaflet map scripting l...

Looks like normal behavior when you have D9-only version.

znaeff’s picture

Thanks for the feedback!

GrahamShepherd’s picture

Perhaps deletion of line 6 in cleantalk.info.yml will fix it.

That is, remove:
core: '8.x'

Such a statement does not exist in other contrib modules, just:
core_version_requirement: ^8 || ^9

_kom__’s picture

I think it is for comatibility with core < 8.8.0

znaeff’s picture

This version supports Drupal 8 and Drupal 9:

https://www.drupal.org/project/cleantalk/releases/9.1.1

znaeff’s picture

Status: Needs work » Fixed
_kom__’s picture

Why you can't do a simple thing but always generate a huge quest?
Now again I can't to upgrade to D9 if I'll update to 8x-4.2, because it is again incompatible.
So I need at least to manually change composer.json to get a fully compatible 9.1 branch version. And I have to hope that this version doesn't contain new bugs besides fixed ones.

znaeff’s picture

We will check this.

znaeff’s picture

Our developers say that this is necessary due to different architecture. Directive core_version_requirement supported by Drupal 8.8 and higher. Drupal version lower than 8.8 requires directive core

GrahamShepherd’s picture

The yaml file already contains:
core_version_requirement: ^8 || ^9

So compatibility with 8 and 9 is correctly declared.

I suspect that the D9 problem is just the existence of the additional but incompatible statement:
core: '8.x'

So, just remove that latter statement.

I'm not an expert but that's how it appears to me.

GrahamShepherd’s picture

My experience is that the D9 version
composer outdated "drupal/*"
Returns:
"drupal/cleantalk 4.1.0 9.1.0".
So it's still not fixed for me.

Glomberg’s picture

For your installation (drupal 9) you have to use cleantalk 9.1.1 release, so fix the dependence in your composer.json to "drupal/cleantalk": "^9.1"
The 9.1.1 release contains only merged commits from the 8.x branch, no new features.

_kom__’s picture

1. Now I use core 8.9.7 and need to upgrade to D9.
2. For what reason have you removed D9 compatibility from 8x branch?
3. So I do not see now 9x version in the available updates section of admin panel. Running 'composer update' leads only to update to 4.2 version, which is incompatible with D9.
4. So what is the deep reason for preparing 'D9 conpatible version" for core 8x users that want to upgrade to D9?
5. You are the only developers that have prepared D9-only version without making previous working version compatible and free of bugs.
6. Direct upgrade to major versions on production site is forbidden for us without deep testing due to safety and security policies.
7. So we need to stop upgrade to D9 (we can not) or to remove module.

8. The easiest way to end the problem is to return D9 compatibility to 8x-4x branch.

Glomberg’s picture

For the full compatibility with D9, we have to add the 'core_version_requirement' directive and remove the 'core' directive from our yml at one time. But we need to continue supporting our clients with old drupal core versions (<8.8). We can't remove the 'core' directive from our current 8.x version. So we have added a new branch and release for support D8.8+ and D9+. You have to reinstall version 9.1 of cleantalk module and change the version in your composer file to 9.1. This allow you to test the module and upgrade drupal core. For the future this version will be the main developing branch.

_kom__’s picture

@Glomberg
Did you read carefully what I've written? One line in code is not the killer-feature to be a major release.
At least you can make a separate branch, e.g. 8x-5x for D9 compatibility (^8.8 || ^9) and leave 8x-4x only for older versions of Drupal core.
(By the way, nobody can upgrade from core 8.3 to 9 without intermediate upgrade to 8.8 or 8.9).

Glomberg’s picture

We have made a separated branch and named it by drupal naming convention https://www.drupal.org/node/1015226
So 8.x will be an old branch and 9.1.x will be a new development branch and will contain new releases. How it was with the old cleantalk module for drupal 7.

_kom__’s picture

@Glomberg
Did you read carefully what I've written?

Waiting for your final decision for two business days.

_kom__’s picture

By the way - II.
Even if I change my local composer.json to ^9.1 I do not see this release in available updates (Composer finds this release, see screenshots).
So, 9.1.1 version compatible with Drupal 8.9 only partially (while 4.1.0 was FULLY compatible, except one minor notice) and we are returning to the very beginning of issue.

_kom__’s picture

Version: 8.x-4.0 » 8.x-4.2
Status: Fixed » Needs work
Serge-M’s picture

Thank you for your reply.
I've passed your details to the programmer staff.
We will write back to you within 24 hours. Please, wait.

GrahamShepherd’s picture

Excellent. 9.1.1 installed and
composer outdated "drupal/*"
returns nothing.
Thanks for all the effort and patience with my inexperienced intrusions.

_kom__’s picture

Now I see 9.1.1 in available updates in admin panel. Thanks for fixing tags.

_kom__’s picture

Nevertheless.

1. 9x release of Cleantalk is not the same as 8x-4x, because for a long time these branches have been developed separately. We know almost nothing about it's behavior: according to statistic page only about 2% of total installations have been performed with this branch. Moreover, looking at last incidents we may assume high probability of bugs in it. For now this branch is a pig in a poke.
2. The best way and the common practice is to prepare a final release of previous branch totally free of known bugs and fully compatible with 8.8 and 9.0 versions of Drupal core and only then make releases of new, higher branch. Actually the very first higher release must be a clone of previous stable compatible release (except of core compatibility maybe). And only then you go forwards and make improvements, create new features for higher core, fix new bugs and so on.
3. It is not a right way to force user to install not well-tested release, especially when module requires a paid account.

Glomberg’s picture

1. No, you are incorrect. The 9x branch is merged with the 8x branch so they are identical.

2. We can not include the necessary changes to the 8x branch. The reason is that the clients who use the old version of Drupal would see errors of incompatibility when they update the plugin.

3. You can keep using the 8x version but if you plan to update Drupal to the 9x version then re-install the plugin v9.1.x beforehand.

4. Please, send me a few examples of the plugins which support Drupal 8/9 in a different way.

Glomberg’s picture

Status: Needs work » Fixed
_kom__’s picture

Module should not prevent core upgrade except only one specific case: when some module is totally incompatible with higher core version. This is true for any version, patch, minor or major and this is modern Drupal ideology.
We have successfully upgraded to D9 including production site staying on 8x-4x branch (as a temporary solution).
Hope that soon we'll see much more evidences of Cleantalk 9x branch stability including usage statistics and lack of critical issues. Then we'll certainly upgrade.

_kom__’s picture

(Right way and timeline for development of different branches that doesn't produce compatibility issues you can see e.g. here: https://www.drupal.org/project/leaflet/releases)

Status: Fixed » Closed (fixed)

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