Stable releases on 8.x-1.x and 2.0.x

I'll read this in more depth later, but just passing by to post a link to https://www.drupal.org/project/drupal/issues/3357742 🌱 Guidelines for semantic versioning and Drupal core support Active which AFAIK is the most up-to-date ideas on the matter.

General gist of it being that an admin doesn't need to update any contrib modules at the same time as you're updating Drupal or Commerce Core. And not adding a new major release at a drop of a hat, mainly to keep with the exiting release system of d.o site. It's what I've aimed to do on all the projects I'm involved with as I am usually in the middle of upgrading a site from one of Drupal 7 -> 8 -> 9 -> 10 -> 11.

The new plan lines up with that. Keeps Drupal 9 support because Commerce is still supporting it.

I did have one more alternative plan, but I don't think it fits as well as it makes a branch which then becomes useless as soon as the next release of Commerce Core.

• 8.x-1.x branch would handle D9+C2 -> D10+C2 -> D10+C3
• 2.x (2.0.x) branch would handle D10.3+C3 -> D11+C3
• 2.x (2.1.x) branch would handle D10.3+C3.1.1 -> D11+C3.1.1+Attributes

Is supporting both C2 & C3 in the same code possible?

For plugin attributes, we can have both the attribute and the annotation on the plugin together.

For this module, supporting Commerce 2 and 3 is possible, but only using Annotations. I had the tests running on D10+C2 with my initial changes, and now it's running tests on D10+C3, and I've done the same on production. It would be great to be able to control the version of Commerce during the GitlabCI build phase of running tests - locally I've just been editing the composer.json file to switch between 2/3 for tests.

Using the Attribute here when on Commerce <=3.1.0 causes a WSOD because of #3542545, which is why there needs to be a separate branch for supporting that. Using Annotation + Attribute would not help in such a circumstance.

As the module stands it can support both Commerce 2 and 3 - it wasn't actually specified in the composer.json file because it relied on Commerce's composer requirements to function, but now that Commerce doesn't include inline_entity_form (and they had that dead 2.x branch) I felt it was better to explicitly specify supported version. The next branch will explicitly only support ^3.1.1 along with improvements only possible after Drupal 10.3, or 11.2.

Being able to support Commerce 2 and 3 also means that an admin doesn't need to be upgrading this module at the same time as Commerce Core, which goes back to the linked guide (or plan for a guide?). It's best to be able to update just Drupal/Commerce core, or just a contrib module, providing clean steps forward. Nothing quite so bad as having to step composer forward with "--no-update" with bunches of modules in a specific order to break out of dependency hell.

Anyway, I think I've convinced myself that this is the way forward:

• 8.x-1.x branch would handle D9+C2 -> D10+C2 -> D10+C3 -> D11+C3
• 2.x (2.0.x) branch would handle D10.3+C3.1.1 D11+C3.1.1+Attributes

The the 2.x branch would postpone release until Commerce 3.1.1 is released.

Re: Commerce 2 GitlabCI testing

The main reason I've had to push forward with upgrading sites at present is because Commerce 2 support was pulled last month before being re-instated this month sometime. Really threw a spanner in works as there are modules which don't support C3 yet that are in use, and then people want to push all the way to Drupal 11 instead of just upgrading Commerce.

I'm not sure I'd want to spent time getting automated testing going for two different Commerce versions if it's about to be pulled anyway. If someone already has it worked out, I'm all ears, but I just want to provide an easy upgrade path for those still stuck on Drupal 9. Those poor suckers on Drupal 8 are already forking everything.

> It would be great to be able to control the version of Commerce during the GitlabCI build phase of running tests - locally I've just been editing the composer.json file to switch between 2/3 for tests.

You should be able to specify the version of a dependency -- see https://project.pages.drupalcode.org/gitlab_templates/info/common/.

If you add a requirement for 'drupal/commerce ^3' there, while in the module's dependencies it's '^2 || ^3' then it'll resolve to 3.

> Using the Attribute here when on Commerce <=3.1.0 causes a WSOD because of #3542545,

I don't think we need a separate branch for that. Use a 'conflicts' for '>= 3.0.0 || < 3.1' and that should work.

I think what I would do is try to add support for Core 10/11 and Commerce 2/3.1 while still on the 8 branch. It's fine to have the support in the code, but say that we won't *actively* maintain support for Commerce 2 -- in other words, we'll commit patches, but that's it.
If that works, then great.
If we hit a problem that means we can't support both, then we need to make a new major.

Automated tests are currently defaulting to Commerce 3.x based on the current require string, so no need to mess around there. I was more curious about setting it up so that it created both a Commerce 2 and 3 build to run them. It looks like it would be possible with the settings there when scheduling it but if C2 is close to EOL I don't think it's necessary to work on.

I've updated code in 📌 Automated Drupal 11 compatibility fixes for commerce_profile_pane Needs review to support D10/11 + C2/3 in the 8.x-1.x branch. With 🐛 Call parent::buildConfigurationForm Active merged in before it, that would make a good point for the 8.x-1.0 release, unless it needs another beta or rc. The D11 fixes continue to use Annotations to support C2/3, but it does issue depreciation notices.

The 2.x branch can be postponed. There are a pile of code cleanups I'd like to do but they require either D10.3 or D11.2, along with the release of Commerce 3.1.1. That new branch would be D11.2/C3.1.1 dependant to allow the full transition to updated methods without BC. It would still be a straight upgrade step.

Update summary to reflect new plan of only doing 8.x-1.x branch stable release which support Drupal 9.3 to 11. It uses only legacy code which will not be supported into Drupal 12.