Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.7k
[Console] Remove deprecations across the component#50613
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
[Console] Remove deprecations across the component#50613
Uh oh!
There was an error while loading.Please reload this page.
Conversation
903ba6a to171965fCompare
nicolas-grekas left a comment• edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
let's finish existing PRs before opening new ones ;)
Uh oh!
There was an error while loading.Please reload this page.
171965f to740e684Compare| "composer/composer":"^2.6", | ||
| "symfony/console":"^6.4|^7.0", | ||
| "symfony/dotenv":"^6.4|^7.0", | ||
| "symfony/finder":"^6.4", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
This is necessary becausecomposer/class-map-generator doesn't supportSymfony ^7.0 yet. The highest dep for the Finder must be set to^6.4 because of this for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
please send a PR to class-map-generator instead
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Unlocked!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I was going to update when I saw you updated the file. Thank you! 🙂
Uh oh!
There was an error while loading.Please reload this page.
1a9a9f0 toa1854beCompare| try { | ||
| // "symfony" must be kept for compat with the shell scripts generated by Symfony Console 5.4 - 6.1 | ||
| $version =$input->getOption('symfony') ?'1' :$input->getOption('api-version'); | ||
| $version =$input->getOption('api-version'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
What about this one@wouterj? should we keep support for the deprecated flag to provide a smooth transition?
Also, we're missing a deprecation notice if this should be removed in 7.0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
This was modified by#46901.
We need to keep thesymfony option if we want developers to be able use to bash completion for different projects with different Symfony versions on the same computer. The completion script insymfony/console from 5.4.x to 6.1.x sets the option-S but not-a. If the option is removed, the_complete command will fail.
| local completecmd=("$sf_cmd""_complete""--no-interaction""-sbash""-c$cword""-S{{ VERSION }}") |
We can fallback toapi-version=1 when not specified.
| $version =$input->getOption('api-version'); | |
| $version =$input->getOption('api-version',1); |
It would be better to make this change in a dedicated PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
If I understand correctly, here is what you suggest:
- Create a PR targeting 6.4 as a new feature, making
api-versionfallback to1 - Update
symfonyoption deprecation to be removed in 8.0, when 5.4 is EOLed.
I'll take care of this if it is what you meant
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I think we should revert this change completely and leave it as-is. Notice the comment says "kept for compat" without deprecating the old one, which is intentional.
Shell completion scripts are global and there is no reason to make life extremely difficult for developers that work on several Symfony versions, some of which are older than 7.0, for the gain of removing these 2 LOC :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
This suits me fine. As you said, these are just 2 lines of code 😄 I reverted this change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Do I have something to do with this?
| $this->assertSame('This is a command I wrote all by myself',$command->getDescription()); | ||
| } | ||
| publicfunctiontestAttributeOverridesProperty() |
nicolas-grekasJun 29, 2023 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
this one is not legacy 🤔
alexandre-dauboisJun 29, 2023 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
That's right, but now that$defaultName and$defaultDescription are removed, it feels irrelevant to me to have this test. I guess this should have been marked as legacy as well when the properties were deprecated? Or maybe am I missing something?
However, I may update this test with a command without the attribute and checking that thegetDefaultName() andgetDefaultDescription() are null
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
We should still keep it to ensure no regressions on the topic. (Removing depreciation annotations on the fixture)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
That's reverted and updated 👍
36591f1 to41d1515Compare41d1515 to6c89c12Compare6c89c12 to7e81c91CompareThank you@alexandre-daubois. |
Uh oh!
There was an error while loading.Please reload this page.
In short: preparing the component for 7.0 🙂