Drop support for D10.0, 10.1

(clarify issue title)

I've created a merge request. Feedback welcome!

I would only support ^10.3 || ^11, as 10.3 provides almost the same public API as Drupal 11.0.

There is also a warning in the upgrade status test: The drupal/core requirement is not compatible with the next major version of Drupal. Either remove it or update it to be compatible. We should disable upgrade status test for now also in branch 5.0.x (it's already disabled in 4.0.x).

Done! I'll put this issue back for review!

I was hesitant to drop support for 10.2 before its support is officially dropped, because one of the organizations that is paying for my contributions to ckeditor_abbreviation is still on 10.2... but my client's D10.3/D11 upgrade plans are progressing nicely, so as long as ckeditor_abbreviation-4.0.x remains supported while 10.2 remains supported (i.e.: until the end of 2024), then it should be fine (and as a co-maintainer, I'm happy to continue supporting that branch until the end of 2024).

But, I agree with your reasoning - it will be much easier to support Drupal 10.3 and 11 going forward.

Regarding the upgrade status job...

My understanding is that the module that the job runs to generate the report → gets updated frequently so that it is aware of APIs that are deprecated in D11 and removed/changed in D12.

So - in theory - this job is supposed to notify us as soon as an API that we are using becomes deprecated, i.e.: giving us lots of time to find a solution/workaround (or push back in the core issue queues). In practice, however, its introductory blog post doesn't really have much information on how we're supposed to use it once it is set up.

On the one hand, it seems strange to say that ckeditor_abbreviation supports D12 (i.e.: by changing our core_version_requirement to (i.e.: ^10.3 || ^11 || ^12) before D12 even has an alpha release. But, on the other hand, seeing the test failure because of our core_version_requirement makes it easy to get into the habit of ignoring the output from that job (i.e.: because it always fails), leading us to miss when an API that we actually use is removed/changed.

So... what could we do?

1. We could leave it disabled until a D12 alpha version comes out; then re-enable it and update our core_version_requirement at the same time.... but if we do that, instead of fixing old API usage gradually over the next ~2 years, those problems will pile up and we won't notice until we re-enable the job after the first D12 alpha comes out. And, this approach would make it hard to test for people to test ckeditor_abbreviation on D12 in the meantime.
   • Note that I have disabled the job for now, so we've already started on this path.
2. We could mark the 5.0.x branch as compatible with D12, so that the upgrade_status report is successful... but if we do that, then we're not really being entirely truthful about our D12 support (i.e.: we're only supporting it on a best-effort basis, i.e.: only fixing D12 support when we notice an issue in the report and we have time to fix it).
3. We could create a 6.0.x branch that is compatible with D12, enable the upgrade_status job on that branch, and leave it disabled it on the 5.0.x branch... but if we do that. we will have to remember to merge our own ckeditor_abbreviation issues to both branches (and there is a chance that people might be more-hesitant to contribute a fix to a 6.0.x branch that they don't use yet).

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