First and foremost: thanks for maintaining such a helpful and critical module.
I am not arguing that there should be test support for D10 and D11 in the 2.x branch of the code, but I am arguing that if there is code that is not backwards compatible, that it should then be moved into the next major release 3.x.
People expect code to stick to semantic versioning. Therefore it should be possible to go from, let's say 2.0.0 to 2.2.0 because semantic versioning defines that minor versions will only add functionality in a backward compatible manner. This is not the case. You can only go from 2.1.4 to 2.2.0.
Composer sticks to semantic versioning. If code is not ready for a release yet, it would need at least a beta or rc1 flag in the tag. This does exactly what you are proposing, as it would only install a stable release when a minimum stability is defined. So if the change would've been 2.2.0-rc1, then it would not have installed it if the minimum stability is set to stable on a ^2.1 requirement. But even then, it will break once 2.2.0 is released and people didn't update to 2.1.4 beforehand.
For example, if you would've installed Drupal Starshot (Drupal CMS) two weeks ago and ran composer update -W now, it would break, as it does require "drupal/honeypot": "^2.1" here.
I don't think Drupal has specifically documented whether this is "allowed" or not. At the end of the day the decision is up to you, the maintainer, and we as "consumers" are at your mercy. I don't want to make this into an argument, and we will work on implementing the workaround update path whether you release the proposed revert or not.
But based on the recommended way of requiring and updating Drupal modules with composer, it will break thousands of update workflows. The case for me being, that I will have to do these steps for 100s of websites. See the original report in 3468450 🐛 Update to version 2.2 results in error warning updating database. Needs work ; I think reports like these will keep pouring in.
This is a breaking change in a minor release. People won't be able to upgrade to 2.2.x from any lower version of 2.x other than 2.1.4. If this is only to remove some "unnecessary" code I would argue in favor of keeping it in the 2.x branch by reverting commit 4be4c190 and releasing a new patch version on 2.x (e.g. 2.2.1).
@TR As others have pointed out this is a breaking change in a minor release which is not expected according to semantic versioning. For people using automated deployment system, they will have to specifically require and deploy 2.1.4 or ~2.1.4 to move to another feature release. If there are incompatible changes to previous versions it should be done in a new 3.x major release.
As the change from
#3464350
📌
Remove obsolete update hooks and update tests
Fixed
is due to the update hooks "not [being] relevant anymore in 2.2.x", is there a chance that we could get the commit 4be4c190 reverted in the major version 2.x, with a new patch release (e.g. 2.2.1), so there are no breaking changes for people updating on 2.x? In my opinion some "unnecessary" code is better than breaking changes on such a wide-spread module.
The merge request !115 doesn't contain the same changes as the 3462233-mb-encode-numericentity branch. The former just deletes the sanitation completely while the latter fixes the deprecated function. We'll creating an internal ticket to test backwards compatibility and resolve this.
martinstadelmann → created an issue.
martinstadelmann → created an issue.
Improvements released in gtl 3.0.5 → .
martinstadelmann → created an issue.
martinstadelmann → made their first commit to this issue’s fork.