Problem/Motivation
At time-of-writing, all versions of Drupal 9; as well as Drupal 10.0, and Drupal 10.1 have been deprecated.
(Note: Drupal 10.2 is still covered for security fixes until December 2024)
This module still says it supports D9, but Drupal.org doesn't provide any test infrastructure to test on D9 anymore, and the module maintainers don't use Drupal 9, so we don't know if our changes will break it. To add complexity, some older versions of Drupal core support older PHP versions which are out-of-date.
Further, maintaining support for older Drupal APIs and PHP versions...
- holds us back from using new API/language features that save us time
- costs the module's (volunteer!) maintainers time and energy, which are already in short supply
Also, our tests on D9 no longer work because \Drupal\Tests\field\Traits\EntityReferenceFieldCreationTrait doesn't exist in that branch, so we won't really know if we break support for D9.
Proposed resolution
Drop support for all versions of Drupal 9. Drop support for Drupal 10.0. Drop support for Drupal 10.1.
Remaining tasks
Write a patch to drop supportReview and feedback from the communityRTBCCommitRelease- released in 8.x-2.0-rc1
User interface changes
None.
API changes
None.
Data model changes
None.
Issue fork sitemap-3465600
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
mparker17Putting into "Needs review".
If you use sitemap on an older version of PHP or Drupal (especially any version of Drupal 9, Drupal 10.0. Drupal 10.1, and/or Drupal 10.2), we want to hear from you in this issue!
Comment #4
dcam commentedI don't use Sitemap on versions that are EoL, but I am a fellow contrib module maintainer. For a long time I left compatibility for old versions of Drupal Core in my modules, even back to D8. It's only been in the last month while prepping for the D11 release that I finally stopped that practice.
My biggest concern at the time was whether I should drop support and then issue a major release or if it could be done in a minor release. I've seen both approaches in other modules. My strict reading of semver suggested that it would necessitate a new major release and that's why I'd always held off. So I did a search for info and found #3357742: Guidelines for semantic versioning for contributed projects in relation to Drupal core compatibility. I found myself agreeing with the side that says "drop support in a minor release." Now my thinking is that declaring your compatibility with Core isn't the same as declaring it as a dependency. So it's ok to say "We're no longer compatible with these versions" in a minor release. And as you said, we can't test against older versions, so you can't make a guarantee about compatibility anyway. With that in mind it could even be harmful to end users if you continue to declare that compatibility.
The end result for me was that I dropped EoL Core support for all my modules. I don't know if that perspective will assist you in making your decision, but I hope that I helped a little.
Comment #5
jackfoust commentedIt would be great to see 10.2.x supported until its security coverage expires in December 2024, but I understand the need to move forward!
Comment #6
jenna.tollersonDitto to this. We try to stay relatively up-to-date, but not everyone can move to the latest and greatest at the same pace. :)
Comment #7
mparker17Thank you for the feedback everyone!
I have no issues continuing to support 10.2.x until its security support ends (I honestly didn't know it was still supported!).
I'll update the issue title, issue summary, and merge request accordingly.
I'm going to leave this issue open for a bit longer to gather more responses.
Comment #8
jackfoust commentedThanks @mparker17!
Comment #9
mparker17I discovered today that our tests on D9 no longer work because
\Drupal\Tests\field\Traits\EntityReferenceFieldCreationTraitdoesn't exist in that branch, so we don't really know if we break support for D9. I've added this to the issue summary.Also moving to "Needs review" to encourage the community to review it!
Comment #10
dcam commentedIf part of the code can't be run on D9, then the new version is officially incompatible with D9. A top module like this one likely has orgs running the automated tests as part of their deployment process. If any of them happen to be on D9, then those tests will fail. It's time to remove compatibility.
I reviewed the MR and it looks good to me. This is RTBC.
Comment #11
mparker17Thanks for the feedback everyone! I'll merge the code shortly.
Comment #13
mparker17Merged!
Comment #14
mparker17(Changing the issue title slightly)
Comment #16
mparker17Updated issue summary to note we committed the patch and released it in 8.x-2.0-rc1.