Symfony 5 compatibility #917
Labels
Comments
|
Yeah, this is important. Time for Robo 3.0? |
|
We won't need to bump the major version of Robo unless we make breaking changes to support Symfony 5. If code changes are needed, we will do a ^3 of Robo. I think I've seen projects using ^4 | ^5 of Symfony, so it might be possible that we can avoid code changes. There are a few other dependencies of Robo that have to support Symfony 5 before we can add it here. |
Uninstallable because of consolidation/self-update and consolidation/log, which refer to ^4 |
|
Hello! Do you have any update on this? |
greg-1-anderson
added a commit
that referenced
this issue
Apr 13, 2020
|
There were a couple dependencies keeping us from doing this. Fixed one and removed coveralls; that allowed me to create a PR to try it. |
|
See #940 for comments on things that need to be fixed for Symfony 5 support in Robo. |
|
Can it be check that constrains are loosened so that when Symphony 6/7/8/etc comes there is no need to update again, if there are no breaking changes? If it takes 6 months for such a relatively minor update we risk Robo to be unusable for quite some time during any update of Symphony. Or even look at revising the requirement of so many dependencies on external libraries? |
|
How would we know if the current version of Robo worked on Symfony 6 prior to its release? Note that code changes to Robo are required for Symfony 5 compatibility. |
|
Excellent point. Which is why I would say removing the dependency is probably the best way forward. For instance can the Symphony code be downloaded and added to the Robo namespace? |
How long an update takes is dependent upon how important it is. Robo is open source; folks can submit PRs for Symfony 5 compatibility if they need it.
Robo is not unusable during a Symfony update; you may continue using Robo with the supported version of Symfony. Making a private copy of Symfony in Robo is not a good solution. It is a feature that Robo uses Symfony, and is therefore interoperable with any additional Symfony-based package you might want to include and use with Robo, e.g. passing a Symfony object from Robo to an external API. |
It is! I upgraded to SF5 and symfony packages are now required in 5.0.x versions so I can't install Robo anymore |
|
Maybe more folks should submit pull requests fixing SF5 issues if upgrading is important. |
|
I second @iciantoine and its a very valid point because Robo is quite an important tool and lots of people rely on it. |
|
Awesome. Two votes in favor of more community involvement with creating PRs to keep things up to date. |
|
my personal opinion is not to directly depend on robo in a project. use robo is a ci-, deploy-, taskrun-, ...-tool. for me its like a binary file which dos stuff. i don't want my project to break just because a tool written in for example c changed its dependencies. the same way i look at robo. in my project there is a in my opinion this tool dependencies must not interfer with the project dependencies or you end up in dependency hell. the readme ist not up to date (only used by me and @vworldat but i think you will get a direction https://gitlab.com/c33s-group/robofile/-/blob/master/README.md |
|
c33s's model is the best; if you are not using Robo to build your application (c.f. Drush, Terminus), then you should just use a separate application, bundled with the task plugins you need. |
|
Many issues fixed in #205, but a few remain. |
|
This should largely be fixed by the 2.1.0 release. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Steps to reproduce
Add a Symfony 5 package to your
composer.jsonfile:{ "require": { "symfony/process": "^5.0.0" } }Expected behavior
The installation of the Symfony 5 package succeeds.
Actual behavior
It would be cool if the version constraint of Symfony packages was relaxed. Something like:
{ "require": { "symfony/console": "^4.3.5 || ^5", "symfony/event-dispatcher": "^4 || ^5", "symfony/filesystem": "^4 || ^5", "symfony/finder": "^4 || ^5", "symfony/process": "^4 || ^5" } }See the Symfony policy about backward compatibility:
https://symfony.com/doc/current/contributing/community/releases.html#backward-compatibility
The text was updated successfully, but these errors were encountered: