silverstripe / .github

0 stars 2 forks source link

Add symfony 7 support to vendor-plugin and recipe-plugin #325

Open emteknetnz opened 1 month ago

emteknetnz commented 1 month ago

silverstripe/vendor-plugin:^2 and silverstripe/recipe-plugin:^2 both have some method signatures that assume symfony 6 is being used

CMS 6 uses symfony 7 and there don't appear to be any issues with this in the CI builds for CMS 6. However we've had community feedback that there are issues is some circumstances with this in this issue and this issue.

It probably makes sense to release v3 versions for both of these modules to be released that have method signatures updated to match symfony 7, and to update any CMS 6 modules that use these modules accordingly

Related issues

Acceptance criteria

GuySartorelli commented 1 month ago

CMS 5 modules remain on ^2

Given this seems to be about what version of the symfony library is used in composer, it might be sensible for us to have a ^2|^3 constraint for CMS 5. That way it will be forward compatible with later composer versions.

emteknetnz commented 1 month ago

I'd like to avoid dual support as it caused a lot of maintenance problems in CMS 4.

The "used in composer" part of this I'm finding fairly confusing. I'm making the assumption here that composer means the composer/composer dependency that's installed with silverstripe i.e. in a CMS 6 kitchen-sink installed e.g. composer show | grep composer/composer will show 2.8.1 on my local.

I don't think ^2|^3 for CMS 5 makes any sense? What good would the ^3 do for say silverstripe/vendor-plugin (required by silverstripe/framework)? CMS 5 requires symfony 6. If silverstripe/vendor-plugin:^3 is type hinted for symfony 7, then won't that then cause an issue since it's being installed with symfony 6?

GuySartorelli commented 1 month ago

I'm making the assumption here that composer means the composer/composer dependency that's installed with silverstripe

No, I mean literally composer, as in when you run composer require silverstripe/framework. Composer is a PHP project that has PHP dependencies. The plugins plug into composer, so they need to be compatible with its PHP dependencies.

GuySartorelli commented 1 month ago

I don't think ^2|^3 for CMS 5 makes any sense? What good would the ^3 do for say silverstripe/vendor-plugin (required by silverstripe/framework)? CMS 5 requires symfony 6. If silverstripe/vendor-plugin:^3 is type hinted for symfony 7, then won't that then cause an issue since it's being installed with symfony 6?

The dependencies required by silverstripe's various modules are entirely irrelevant. The plugin needs to be compatible with the dependencies that the installed version of composer on the user's host machine is using when they run composer vendor-expose or composer require, etc.

emteknetnz commented 1 month ago

The plugin needs to be compatible with the dependencies that the installed version of composer on the user's host machine is using when they run composer vendor-expose or composer require, etc.

Well, it's certainly a confusing topic

My understanding is that composer is installed as a downloaded phar which is over 100K lines long and has all its own composer dependencies i.e. the entire vendor folder "baked in". So that's what the dependencies on the host machine that composer is using are?

My local is running PHP 8.1 (for CMS 5 compatibility) and composer 2.8.1, when I installed composer did I get a version with symfony 6 support? Or symfony 7 support? Did I simply download the pre-baked composer.phar hosted on the 2.8.1 release page? Or does I get a dynamically generated one based on my local environment? Symfony 7 requires PHP 8.2. I can run composer vendor-expose on a CMS 6 project with no issues

In CI we're using shivammathur/setup-php which will happily install PHP 8.3 with symfony 7 for Silverstripe modules and run a bunch composer commands and the dev/build with no issue

If what you're saying is correct about "The plugin needs to be compatible with the dependencies that the installed version of composer on the user's host machine" - it seems that putting ^2|^3 for silverstripe/vendor-plugin in silverstripe/framework's composer.json will only take into account what silverstripe/framework wants, not what the composer on the host machine wants?