- Issue created by @pfrenssen
- 🇨🇦Canada endless_wander
Thanks for starting this. I would like and need a D11-compatible version without any other feature changes or updates as I will be migrating our sites to D11 very soon. Other modules have been creating minor updates introducing the bare minimum for D11 compatibility. I was planning on spending some time this month to see how much this module needs for that minimum compatibility and it would be great if we could have at least one release still on the 2 branch without needing to check on updating a whole ton of stuff just for D11 compatibility.
- 🇧🇬Bulgaria pfrenssen Sofia
If you can make an MR with the minimum necessary changes to get D11 compatibility while still retaining full backwards compatibility with Drupal 9.3+ then that is very welcome. But let's do that in a dedicated issue, this issue is specifically on future forward changes and does not affect 2.x.
- 🇨🇦Canada endless_wander
Perfect, I have time planned at the end of the month and early November. I just wanted to make sure we were addressing D11 compatibility in 2 branch as well.
- 🇺🇸United States Chris Dart
chris dart → made their first commit to this issue’s fork.
- 🇺🇸United States Chris Dart
I have made some commits to get this to be minimally D11 compatible. These are unrelated to the other child issues here which appear to aim to clean up and make the code more modern.
- Merge request !146Issue #3479860 by pfrenssen, divyansh.gupta: Fix constructors which have... → (Open) created by Chris Dart
- 🇪🇸Spain plopesc Valladolid
Hello @pfrenssen!
I really like the idea brought in this issue. Last week I started to work on a similar upgrade path for Field Inheritance module. You can see how it looks in 🌱 [META] 3.0.0 Plan Active .
Key part of the upgrade would be to integrate the Field Inheritance architecture changes introduced in 📌 Store relation with the parent entity in the database instead of the State API Active , which you actually suggested a while ago.
I'm wondering if we could define a similar approach for Recurring events, where a new 3.x branch is used to define Drupal 10.3+ releases based on Field Inhetance 3.x.
The reason why I preferred to use 10.3 instead of directly a new 11.x branch was to give sites the opportunity to have an stable environment with the new Field Inheritance architecture before moving to 11.x. This approach was taken by Drupal Commerce and the 3.x version. That was very convenient for us in other Commerce based projects, where the migration was taken in 2 steps to reduce friction points.
I'm open to help and collaborate with the migration of this module, given that it's a key requirement in some of our projects. At the same time a review and test of the new FI architecture would be very helpful to ensure that both modules are aligned.