Support Drupal 10 in the 1.0.x branch

Am I right that now with #3306512: Add compatibility with Group v2 and v3 RTBC this issue is also unblocked?

Sure, sorta. ;) I'd rather get Group v1 D10 compatible first, but it's gonna be a little while before I'll be able to work on that. Maybe this can proceed in parallel?

the 2.0.x branch is now D10 compatible. I'll leave this issue for making the 1.0.x branch D10 compatible, which is blocked on a D10-compatible release of Group V1, e.g. #3367539: Initiative for Group 1.x compatibility under Drupal 10 and friends.

Uploading a full patch, which provides Drupal 10 compatibility against 1.0.x-dev branch.

Please test. You will need groups 1.x-dev in order to get this working.

Now that Group v1 supports Drupal 10, can a release be made based off of the most recent patch to get v1 of Entity Group Field to support Drupal 10 as well?

I am also interested in this being in a v1 release so that I can properly focus on the Group v2 or v3 upgrade early next year!

I've rerolled that patch from MR11 against the 1.0.0-alpha2 tag. The changes from #3367521: Configure GitLab CI are not yet tagged, thats why the generated patch from MR11 doesn't apply.

Thanks for the patch @timohuisman !

Sorry folks, forgot this one was still open. Marked #3400137: Providing a version that's compatible with D10 and Group 1.x duplicate. Som things we still need to solve here, not addressed in the current MR:

1. Strong preference not to drop D8 support unless we have to, which I don't think is necessary. Nothing in here actually looks like it requires 9.5. Let's use core_version_requirement: ^8.8 || ^9 || ^10
2. Drupal\Tests\entitygroupfield\Kernel\GroupAutocompleteFormElementTest::testGroupAutocomplete
   LogicException: system module does not define a schema for table 'key_value_expire'.
3. We also need to tweak the .gitlab-ci.yml file in the 8.x-1.x branch to get this testing on D10. Not sure if we need the full complications of the 2.0.x branch's copy with the "matrix" testing, or if there's a slicker way to have it test on D10 by default but still be able to test earlier versions, etc.

But I'd love to get this resolved, committed and another 1.0.x release tagged ASAP.

Thanks!
-Derek

Fixes #18 except for #18.3 and the .gitlab-ci.yml file.

Decided to move #18.3 to a follow-up (#3401957: Fix GitLab-CI configuration on both 1.0.x and 2.0.x), since it doesn't have to block the release and isn't directly related to the D10 compatibility in the code itself.

1.0.0-beta1 is now out! 🎉

@dww
First Thanks for the great work and rolling out a new release!

Strong preference not to drop D8 support unless we have to, which I don't think is necessary. Nothing in here actually looks like it requires 9.5. Let's use core_version_requirement: ^8.8 || ^9 || ^10

General question: I also maintain the contrib modules. If the Drupal core doesn't support the D8 and D9. How long as a contib maintainer we should support the unsupported Core?

Like in the case of above commit https://git.drupalcode.org/project/entitygroupfield/-/commit/27c7d0ec2bf... we relied on a core/once library which was introduce in Drupal core in 9.2. See https://www.drupal.org/node/3158256
Now, we're claiming that we support 8.8 but we don't

Sorry for highlighting this here but that's a question general for all projects

You're welcome, and thanks for helping! And for this question:

I also maintain the contrib modules. If the Drupal core doesn't support the D8 and D9. How long as a contib maintainer we should support the unsupported Core?

Not everyone agrees on this, but my strong belief is "as long as you feasibly can". If the exact same code won't crash your site on 3+ different versions of Drupal core, amazing! That makes life so much easier for people stuck on older versions of core, trying to get out of an impossibly complicated web of composer hell. I'd rather make it as easy as we can for our end users to upgrade instead of punishing them for not having upgraded already by artificially making it harder than it already is.

That said, if you want/need to use newer features that only exist in later versions of core, so be it. Start a new minor branch or whatever, and move on. But don't drop support just for the sake of it. If the code still works on 8.8, let it be. If there's real tech debt needed to keep supporting "ancient" versions, declare a new minimum and clean up.

In the specific instance of this once requirement in the library, I'm honestly not sure why that's there. 😂 The entire library definition is from the initial commit (d909330 from jidrone), and it's not clear how much of that we're actually using. I just tested again on a D8.9 site and the widget all seems to be working as planned, even pointing to a non-existent library item. Probably we could remove that line entirely. Regardless, it doesn't crash a test site if there's a missing library. Even if it doesn't work perfectly, at least telling composer it'd be okay to use this version as it was trying to upgrade things, huzzah.

At least that's how I see it...
-Derek