- Issue created by @Liam Morland
- ๐ฎ๐นItaly apaderno Brescia, ๐ฎ๐น
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.)
- ๐จ๐ฆCanada Liam Morland Ontario, CA ๐จ๐ฆ
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. - ๐ฎ๐นItaly apaderno Brescia, ๐ฎ๐น
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. - ๐จ๐ฆCanada Liam Morland Ontario, CA ๐จ๐ฆ
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). - ๐ฎ๐นItaly apaderno Brescia, ๐ฎ๐น
I apologize I was not clear in my previous comment.
composer create-project drupal/recommended-project:10.1
followed bycomposer 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. - ๐จ๐ฆCanada Liam Morland Ontario, CA ๐จ๐ฆ
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 incomposer.json
that it is compatible with older Drupal, but its info files say that it is not compatible. - ๐ฎ๐นItaly apaderno Brescia, ๐ฎ๐น
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 rancomposer update --with-dependencies
, which gave me Drupal 10.3.1 and Webform 6.2.5. - ๐ฎ๐นItaly apaderno Brescia, ๐ฎ๐น
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 bycomposer require drupal/webform:^6
, but that is not updating an existing installation. - ๐จ๐ฆCanada Liam Morland Ontario, CA ๐จ๐ฆ
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
. - ๐บ๐ธUnited States cmlara
@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.6In 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.7This 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)
- Status changed to Fixed
about 2 months ago 9:34pm 19 July 2024 - ๐จ๐ฆCanada Liam Morland Ontario, CA ๐จ๐ฆ
webform 6.2.6 and webform 6.2.7 released as described in #11. Thanks
- ๐ฌ๐งUnited Kingdom alexharries
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
- ๐จ๐ฆCanada Liam Morland Ontario, CA ๐จ๐ฆ
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. - ๐บ๐ธUnited States cmlara
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.
- ๐ฌ๐งUnited Kingdom alexharries
@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.