Migrations command should use the UTC datetime when creating new migrations

[lonnieezell]

By ensuring all migrations are created using UTC, then teams from around the world can work together better.

[MGatner]

To piggyback on this, I think we already discussed it but I would love to see MigrationRunner process migrations universally by their UTC datetime, instead of namespace-by-namespace (which doesn't allow devs to make migrations on top of a module's migrations without intentionally staggering them).

[lonnieezell]

@MGatner You're absolutely right. I knew there was more to the discussion but didn't take the time to search for what it was. So thanks!

That could only work for timestamp-based migrations, though.

[MGatner]

I'm curious what your plans are on version control vis-a-vis namespaces. Right now App gets precise control via $currentVersion in app/Config/Migrations.php, but namespaces must be handled manually with the CLI migrate -n commands. Any plans to unify versions across namespaces, or differentiate the config variable, or some other means of version control?

[lonnieezell]

I haven't gotten back to this just yet, but I'm thinking this will need a modification that records a batch number with each migration, then it can record the fully qualified classname in the database so that it will know which classes across all namespaces were part of that last up and should be brought down.

Just read back over what you wrote though and realized that's not what you were asking. :) To be honest, I've never really used $currentVersion in my work, so I'm not 100% clear what the best way to handle it might be (or if it simplifies things just to rip that out...) Open to ideas on that part.

[MGatner]

After posting that I was thinking "maybe I should have included ditching it". I think that's the way to go - it's a bit vestigial at this point already, and definitely doesn't fit well with a multi-source migration scheme.

[MGatner]

This is wrapped up with the migration refactor! Safe to close.