Start a 2.1.x branch for Entityqueue Form Widget to support Drupal ^11.4 || ^12

Problem/Motivation

#3597892 "Automated Drupal 12 compatibility fixes", comment #9 by rajab natshah decided:

Planing for a smoother upgrade process with: New minor 2.1.x branch to support ^11.4 || ^12. Keep 2.0.x for < 11.4.

2.0.x currently declares core_version_requirement: ^10.1 || ^11 || ^12 after the Project Update Bot fixes were merged via MR !10. The FunctionalJavascript test + CI gating fixes landed via MR !12 (#3611115, all CI jobs green, allow_failure: false), and a draft-revision fix landed via MR !11. A clean branch split gives a smoother upgrade path: 2.1.x = current development targeting ^11.4 || ^12, 2.0.x stays for sites on core < 11.4.

Steps to reproduce

N/A – this is a planning/task issue, not a bug.

Proposed resolution

• Create the 2.1.x branch off the current 2.0.x HEAD (40b26098 – includes the bot compatibility fixes, the draft-revision fix, and the green gated CI).
• On 2.1.x: set core_version_requirement to ^11.4 || ^12 in entityqueue_form_widget.info.yml and "drupal/core": "^11.4 || ^12" in composer.json (plus the test module's .info.yml if it declares its own requirement) – done via MR !14.
• On 2.0.x: set core_version_requirement to ^10.6.0 || ^11.3.0 (keeps support for core < 11.4) – done via MR !15.
• Update the drupal.org project page's supported branches once 2.1.x exists.

Community-agreed practice (drupal.org official guidance)

1. Caret + || across majors is the official form for core_version_requirement – introduced exactly for this: ^8 || ^9 style (change record). The chosen ^10.6.0 || ^11.3.0 and ^11.4 || ^12 are that idiom.
2. Raise the core floor in a new MINOR branch, not a new major – the community guideline from the D10-readiness lesson (#3357742): new majors force every site to hand-edit composer constraints (^1.0 won't pick up 2.0), while a new minor (2.0.x → 2.1.x) lets ^2.0 sites update seamlessly. The 2.1.x split is exactly the recommended shape.
3. Minor-level floors (^10.6, ^11.3) are standard when the code needs newer-core APIs; large modules (Webform, Pathauto, etc.) do the same. Convention note: the community usually writes them without the patch segment (^10.6 || ^11.3), identical meaning; the maintainer's final decision keeps the explicit form on 2.0.x.

Bottom line / final maintainer decision: 2.0.x = ^10.6.0 || ^11.3.0 and 2.1.x = ^11.4 || ^12 – the drupal.org-endorsed pattern; the branch overlap is exactly what #3357742 recommends for smooth upgrades.

Sources:

• core_version_requirement change record
• Semantic versioning guidelines for contrib
• Understanding contrib version numbers

Remaining tasks

• ✅ File an issue about this project
• ✅ Addition/Change/Update/Fix to this project
• ✅ Testing to ensure no regression
• ➖ Automated unit/functional testing coverage
• ➖ Developer Documentation support on feature change/addition
• ➖ User Guide Documentation support on feature change/addition
• ➖ UX/UI designer responsibilities
• ➖ Accessibility and Readability
• ❌ Reviewed by a human
• ❌ Code review by maintainers
• ✅ Full testing and approval
• ✅ Credit contributors
• ✅ Review with the product owner
• ✅ Update Release Notes
• ✅ Release

User interface changes

• N/A

API changes

• N/A

Data model changes

• N/A

Release notes snippet

• N/A