RFC: File management

[dereuromark]

Implements some of the ideas of #822 as showcase

Resolves #475 by allowing to not use namespaces, but anonymous classes.

What do you think? Which ones do we want to pursue?

Open questions:

• Should we change the location from config/Migrations/ to resources/Migrations/ or is it fine?
• Do we want to default to the new style? while still allowing the old ones to work of course

By allowing the old ones to continue to work, we should provide reasonable BC here.

[LordSimal]

I dont understand why we need to wrap the anonymous class in a function.

cant we just get the version from the filename and thats it?

But I am all for anonymous classes for migrations

[dereuromark]

Then you need to change

    public function __construct(int $version)

and setVersion() or alike on it

fair enough for me.

[jamisonbryant]

Should we change the location from config/Migrations/ to resources/Migrations/ or is it fine?

I think it's fine the way it is. Unless we want to move Seeds also? There is currently nothing in the resources/ dir in the Cake app skeleton (5.x) which has likely led to users placing their own files and directories in there. If we move pre-existing directories in there all of a sudden it could be jarring.

Do we want to default to the new style? while still allowing the old ones to work of course

I think if it's configurable it shouldn't much matter. Users can set which style they prefer and forget about it. If we're going to do a major plugin release, we should default to the new version. Perhaps, if we decide to backport this behavior to a 4.x release, we can default to the legacy version.

We could also default to the legacy type and print a message "Baking migration using Legacy template, update 'Migrations.style' to try the new anonymous class style"

[markstory]

Looks good to me 👏

[dereuromark]

If we're going to do a major plugin release, we should default to the new version.

I agree.
Especially since then all CS issues should be resolved and it should be a clean code path as well (I can remove all my silencing for the config/Migrations folder then)

[dereuromark]

Once this is done, we need to also tackle Seeds, as they have the same PSR2 namespace missing.

[dereuromark]

@markstory How do we best proceed here?

And we should probably squash merge to avoid extra conflicts in the future with other PRs.

[markstory]

I think if it's configurable it shouldn't much matter. Users can set which style they prefer and forget about it. If we're going to do a major plugin release, we should default to the new version. Perhaps, if we decide to backport this behavior to a 4.x release, we can default to the legacy version.

We could also default to the legacy type and print a message "Baking migration using Legacy template, update 'Migrations.style' to try the new anonymous class style"

I think we can have 5.x switch to the newer format as long as we maintain backwards compatibility for 'old' migrations that applications might have. Existing migrations should continue to be applied and executed. Ideally with zero effort on the developers' part. It would also be good to have a Configure value (Migrations.style works for me) that enables 'old' migrations to be generated. This would let us cover the scenario of trialing a new migrations version and needing backwards compatibility with older migrations.

If folks want 5.x to only provide the anonymous style migrations, then we'll need to introduce forwards compatibility and tooling to convert migrations over in 4.x.

I think the getting developer experience smooth with this change is going to be important. I personally don't want maintenance toil from my database migrations.

[dereuromark]

Right now both work equally.
Either way we should move forward.