Open emteknetnz opened 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.
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?
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.
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.
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?
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