Make releases to fix version compatibility inconsistency

Releases are not deleted after they are created. It is not possible to unpublish them either, since the form element to publish a release node is disabled.

Since a new release has been created, the previous release will not be linked from the project page. Somebody could select the old release from https://www.drupal.org/project/webform/releases → , but Drupal would show 6.2.5 as new available release. (It would be more risky to install insecure releases, but they are not hidden either.)

I'm concerned about what happens when someone runs composer update. As I understand it, the old version remains available for Composer to update to.

Also Composer should update to latest release available. It should not different from what happens with composer require drupal/core:^10.1, which install Drupal 10.3.1.

Yes, that is what I am concerned about. Someone who is still on Drupal 10.0 or older could run composer update and get Webform 6.2.4, which is not compatible (it needs Drupal 10.1).

I apologize I was not clear in my previous comment.

composer create-project drupal/recommended-project:10.1 followed by composer update, gives me Drupal 10.3.1, the latest Drupal 10.x version. Similarly, composer update would update Webform 6.23 to 6.25, not 6.24.

If my site is running Drupal 10.0, I would not get Webform 6.2.5 because Webform 6.2.5 says it requires Drupal 10.1 in its composer.json. Webform 6.2.4 says in composer.json that it is compatible with older Drupal, but its info files say that it is not compatible.

As further test, I ran composer require "drupal/webform:<6.2.3" and edited the composer.json file to change the constraint from <6.2.3 to ^6. I then ran composer update --with-dependencies, which gave me Drupal 10.3.1 and Webform 6.2.5.

If I update starting with Drupal 10.0 and Webform 6.2.3, composer update --with-dependencies gives me Drupal 10.3.1 and Webform 6.2.5.

The only way I could end up with Webform 6.2.4 is running composer create-project drupal/recommended-project:10.0 followed by composer require drupal/webform:^6, but that is not updating an existing installation.

I'm referring to someone who is running composer update but not changing their Drupal version. They could have their Drupal version constraint set to ~10.0.0 or ^9.

@Liam Morland

The "semver" way (and D.O) way to fix this is to when a bad release occurs you make a new release that corrects the issue.

That would(assuming 6.2.3 was a 'good' release) normally look like:

Release 6.2.4 with wrong constraints (broken)
Add a 6.2.5 tag to the same commit that was 6.2.3 and release. Add a release note to 6.2.5 mentioning it is a rollback to 6.2.3 to help people in the future understand why the release exists.
Fix the issue with 6.2.4 and release as 6.2.6

In this case you might have to do a couple more releases (6.2.3 as 6.2.6 and 6.2.5 as 6.2.7) however it should be recoverable.

This creates a situation where yes 6.2.4 is "bad" however any module using a permissive minor constraint (Eg ^6 or ^6.2, and in this case even ~6.2.0) will 'skip past' the broken release and not experience an issue.

D9 sites get 6.2.6
D10 sites get 6.2.7

This does not immediately fix sites that deploy the broken 6.2.4 to D9, however it allows a 'fast fix' for them of just running composer update and protects users in the future. Any D10 on 6.2.4 will eventually upgrade to the latest (6.2.7+) unless trying to explicitly require the 're-tagged' release (In other words it takes explicit effort to use the broken release).

The diff module just went through this recently, (Q/A in Slack: https://drupal.slack.com/archives/C5ABFBZ5Z/p1718063184202889) See Diff 8.x-1.4-8.x-1.7.

This is a little more complicated if 6.2.4 had schema changes and they were applied as some edge cases can occur however even those are mostly minor as long as you account for them (re-tagged 6.2.3 may need a schema rollback and re-tagged 6.2.4 might need to re-apply the schema with new update hook ID's)

(I really need to document this in a blog post as I seem to give this advice out a couple times a year)

webform 6.2.6 and webform 6.2.7 released as described in #11. Thanks

This has just affected my sites as well. Just as an aside, I don't understand why this breaking change has been released in a minor version update instead of a major, which **usually** (not always I appreciate) is how a major compatibility change is released.

Just a bit frustrating is all ¯\_(ツ)_/¯

/A

Is it expected that removing support for unsupported Drupal versions be done only on major releases?

One thing that would help is if the automated tests would check for inconsistency between the version requirements declared in composer.json and those declared in info files.

Is it expected that removing support for unsupported Drupal versions be done only on major releases?

See 🌱 Guidelines for semantic versioning and Drupal core support Needs review for some conversation on this.

I hold strong opinions on this and others hold their own strong opinions so don’t expect any clear answers.

@cmlara: you wrote this in the linked thread and I couldn't agree more :)

Semver is suppose to at its root covey the risk of that if you changed nothing and ran the program how well would it work. If I'm already on the latest Drupal Core and Latest php its low risk for EOL versions to be dropped, if I'm not its a major risk of breakage and that why dropping version support should signal a Major release in that case to inform me I need to look very closely at the release notes.

:) /A

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