Remove obsolete update hooks and update tests

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

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).

No it's not a breaking change. It's an allowed change, and it uses the built-in Drupal mechanism of hook_update_last_removed() and hook_removed_post_update() to inform site developers and prevent site developers from skipping required updates between versions.

The updates and the tests would have to be ported to D11 in order to keep them, with conditional code added so that they would work in both D10 and D11. Are you willing to do that work then monitor the testing and keep them in working condition for the next two years until D10 is EOL? I'm not.

2.2.x is not marked as "recommended" on the project page, so apparently Drupal's composer facade doesn't pass that information on to composer. Regardless, alpha and beta versions have become meaningless in Drupal because no one will install alpha or beta or dev releases anymore, so nothing gets tested by the community unless it's fixed-point release. If it doesn't work the way you expected, perhaps work in the infrastructure issue queue to expose this "recommended" flag to composer so that composer doesn't suggest you skip a release when updating?

The effort required by you is to just read the error message and take the corrective action of updating to 2.1.4 first, then 2.2.0 if you want. That's a trivial task. I didn't plan on that happening, but now that it has the "fix" is still for you to take those steps because restoring the update and post update hooks would put an unreasonable long-term burden on me. And I am just a volunteer maintainer - I don't get paid for doing Drupal like you do.

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.