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.