What's unclear to me is how this upgrade flow will work. Let me try an explain.

Say we have a discovery class provided by the framework which name was changed. FooDiscovery in v1, BarDiscovery in v2.

Let's say the user does the following:

composer require tempest/framework:^2.0
php tempest upgrade

This won't work, because the tempest console cannot boot anymore

Let's do it the other way around

php tempest upgrade
composer require tempest/framework:^2.0

This won't work because the upgrade command needs to know about the new 2.x changes, which it doesn't.

So I don't understand how this will work in practice? I think the Rector rules are great and definitely the way forward, but how do we actually get them to the user?

The only thing I can come up with is distributing a separate upgrading tool that people run on their project, regardless of which framework version the project is running. Sort of a standalone tool that we know will work. I believe this is the reason why tools like Rector and Mago come as a phar, so that they are self-contained instead of having to rely on the project's dependencies.

@brendt

So I don't understand how this will work in practice? I think the Rector rules are great and definitely the way forward, but how do we actually get them to the user?

I was thinking about this too, first iteration of me working on this was purely in Rector and not via Tempest.
Because for changes like this you don't want/need a running Tempest application, and it would prevent the clashes like you described.

Only tried running it via Tempest because that was a wish or I think it was mentioned in the issue

So yeah, I think we need a different approach. I'm going to make a new repository called tempest/upgrades where we bundle rectors for each major upgrade. Whenever people want to update their Tempest project, they should require that repository, and run rector directly with the correct config (we'll provide it for them via the docs).

I think that's a more viable approach.

@brendt

So yeah, I think we need a different approach. I'm going to make a new repository called tempest/upgrades where we bundle rectors for each major upgrade. Whenever people want to update their Tempest project, they should require that repository, and run rector directly with the correct config (we'll provide it for them via the docs).

I think that's a more viable approach.

Sounds good