Fix deprecation warnings for Symfony 6.1 commands

[tacman]

There are a handful of deprecation errors when following the instructions above using php 8.1, because symfony new will install Symfony 6.1 if the php version is 8.1.

# make sure php is at least 8.1
php -v 
symfony new scheduler_demo --webapp && cd scheduler_demo
composer require guikingone/scheduler-bundle
bin/console cache:clear
echo "scheduler_bundle: { transport: { dsn: 'filesystem://first_in_first_out' } }" > config/packages/scheduler.yaml
bin/console scheduler:list

Since symfony/console 6.1: Relying on the static property "$defaultName" for setting a command name is deprecated.

I can fix these and submit a PR.

[Guikingone]

Hi @tacman 👋🏻

The issue is already solved / merged in main: https://github.com/Guikingone/SchedulerBundle/commit/a116655db2d64e124a302f159f1879f352a6a57d, 0.9.4 should be released pretty soon 🙂

[tacman]

I see. I was thinking that it was prompting to use attributes instead:

#[AsCommand(
    name: 'scheduler:list',
    description: 'List the tasks',
)]
final class ListTasksCommand extends Command

and then remove the ->setName() and ->setDescription() lines.

[Guikingone]

We could use attributes to define commands in the bundle, feel free to submit an PR to do it 🙂

[tacman]

OK. I was hoping rector would have a rule for this already, but alas, no.

Can you give me some guidance on the non-coding part of submitting a PR? That is, I assume I should create an issue, then create a branch to resolve that issue. Should that branch be from 'main'? Or 9.4? Or...?

On Fri, Jun 10, 2022 at 7:31 AM Guillaume Loulier @.***> wrote:

We could use attributes to define commands in the bundle, feel free to submit an PR to do it 🙂

— Reply to this email directly, view it on GitHub https://github.com/Guikingone/SchedulerBundle/issues/279#issuecomment-1152263495, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEXIQNR2U2YUXW36Y6LDBLVOMRQLANCNFSM5YNJ7R3A . You are receiving this because you were mentioned.Message ID: @.***>

[Guikingone]

The branch should be created from main, the coding standard are set via PHP-CS-Fixer and the "compliance" with PHP 8.0 is fixed via Rector, the CI should easily tell us if the PR is not valid 🙂