Drop support for D8, D9, D10.0-10.3

A couple of other thoughts...

1. I'm proposing that the 3.0.0 release be - for the most part - the latest 2.0.x release but without support for old versions of Drupal core, I anticipate the move from 2.x to 3.0.x will be pretty trivial for most users.
   • To make things easier, I don't think we should create the 3.0.x branch until we have buy-in from community members and maintainers and we've decided how long to support the 2.x branch
2. Given that I'm anticipating the move from 2.x to 3.0.x will be pretty trivial, I think it's fair for the maintainers to offer security and bugfix support for the 2.x branch for 6 months before marking that branch as unsupported.
   • If we offer to backport bugfixes to 2.x for 6 months, I don't think we need to rush to get bugfixes in before we create the 3.0.x branch
3. Given that we cannot run tests against older versions of Drupal core, and it is non-trivial to manually test on old versions of Drupal core (and I can't remember the last time I manually tested on old versions of Drupal core for this module), I see officially dropping support for old versions of Drupals as the maintainers owning up to the current reality, rather than a big change.
4. As a maintainer, I don't see any more-detailed stats than the rest of the community: it's entirely possible nobody is using this module on old versions of Drupal core, I can't tell. Usage stats for structure_sync → . Usage stats for Drupal core → .

Thanks @mparker17!

I would recommend doing the following changes:

1 - Create the new major development branch: 3.x
2 - Drop support for all core versions below 9.5
3 - Drop support for all PHP versions below 8.0.0

The requirements would then become:

core_version_requirement: ^9.5 || ^10 || ^11
php: 8.0

Changes would also have to be made to the composer.json file, see:
https://git.drupalcode.org/project/structure_sync/-/blob/2.x/composer.js...

Let me know if you would need any help putting together a corresponding merge request, we would surely be glad to help!
Thanks in advance!

When the following core version will come out, same thing:

Create a new major branch and drop support for the requirements of the the oldest version.
Supporting 3 major core versions in a module major version gives a large widow for users to upgrade core and other contrib modules in different steps and flexible order.

This is what I understood maintaining modules and reading the following post:
Drupal module semantic versioning for Drupal core support

Could you please help us make the suggested changes so we could keep moving forward with other issues and update pending merge requests to point to the 3.x branch?

Thanks in advance for your feedback!

Additionally: Automated testing on Gitlab CI allows running PHPUNIT Tests and PHPSTAN code validation for the 3 currently supported major core versions.
See the changes suggested in issue 📌 Gitlab CI: Broaden Tests coverage and require jobs to pass Active , with MR!47:
Build pipelines: https://git.drupalcode.org/issue/structure_sync-3517495/-/pipelines/465983

See the different jobs for the different types of supported versions.

This ensures a better automated testing coverage and can help reporting many deprecation errors so maintainers can make module's code evolve with the different Core version API changes.

In other words: with all the Gitlab CI optin variables enabled, we should be able to provide a pretty good and standard support coverage of the different versions required by Core.

I agree with the general thrust of @mparker17's proposal here, but I also agree that if we can easily test against the 3 most recently supported core versions (ie. include 9.5 at this point), that makes sense to me. Having said that, I haven't looked at the codebase for structure_sync with an eye to core compatibility lately, so if supporting 9.5 is harder for some reason, then we should consider whether it's worth it (I'd love to hear from folks who are somehow tied to 9.5, in that case!)

But again: if our tests can run (and pass!) easily against all three versions, then presumably supporting all three shouldn't be onerous? I'm not aware of huge breaking changes in core between 9.5, 10.4 and 11, but in my mind if the BC layer to support this becomes too much, that's the point where we cut a new major version branch, and carry on.

That's my 2 cents, curious to hear what others think :)

Looking closer at the linked issue 📌 Gitlab CI: Broaden Tests coverage and require jobs to pass Active , I see that we aren't actually testing against 9.5, but rather PREVIOUS_MINOR and NEXT_MINOR, per these docs → . That's more in line with what @mparker17 was originally suggesting I believe, so just to say I think we should proceed with Matt's suggestion :)

OK, yes, thanks @mparker17 and @spiderman!

Dropping support for versions below 10.3 should be fine as well, just like it's suggested in the MR:
https://git.drupalcode.org/project/structure_sync/-/merge_requests/37/di...

I made the suggestion above at #4 since it would be the most immediate solution to get module's development unblocked .... Not excluding the possibility to further drop support, in another minor version... So essentially both would be possible successively.

But if you'd like to make a bigger version drop right now, that should be fine as well.

However, not making any decision is blocking the development of the project and preventing project's tickets from moving forward.

I'm seeing lots of other modules doing that (dropping version below 10.3), see for example :
https://www.drupal.org/project/commerce_stripe →

@mparker17 let's go?!

Is there anything else you could see that could prevent this issue from moving forward?

Personally, I don't feel concerned at all with this issue and change since all of the project I'm currently working on, or managing are all above 10.3 with recent versions of PHP (8.3.19 security patch).

If a customer came to us with a Core version lower than 10.3 (9.x or 10.x), I would recommend upgrading core and modules + consequently upgrade this module based on the different versions (major/minor), which doesn't really sound like a problem to me.

What does the M of @mparker17 stand for?! 🙂

Just my personal humble opinion.
Cheers !

@dydave I've spoken with @mparker17 about this, and we agree we should move forward on this one, but would like to get ✨ Deprecate passing extra parameters to __construct() to prepare for 3.0.x Active merged first, so we can deprecate using extra parameters on constructors *before* we fork a 3.x branch, so we don't have to maintain those until another major version. I'm planning to review the MR on that issue in the next day or two, hopefully get it merged, and then we can proceed with this one:)

Fantastic! Thanks a lot Derek (@spiderman) for the kind and prompt reply, once again! 🙏

Alright, alright! I'll just back out if you don't mind!! 😅

I can see the module is in super great hands! You've got a great plan! 👌

So I'll just go back to fixing my stack of tickets and modules!! 😅
(I've got so much to do ...)

Feel free to ping me directly at anytime if you need anything, I would be happy to help the best I could 🙂
Thanks again for all the great work and keeping this module well maintained!
Cheers!