Mark Scherer

If @markstory 's plans come to play, bundling all migrations (incl plugins) into one table, then it would make sense. otherwise a rename doesnt make sense (only harder BC break)....

> On average our systems have ~50 _phinxlog tables as we use a lot of Plugins. That just proves his point: merging them into one `cake_migrations` (with BC!) sounds like...

@markstory When creating such a merged table, I would like to see a primary key (int) being added, so we can more easily identify the last ones being added. Right...

> But as long as a cake upgrade phinxlog command exists this should be fine It most likely will happen automatically under the hood. The current migration tables also get...

I dont think we need "upgrade-rebuild" or even "cleanup" The upgrade one could, if no errors, directly remove the phinx table. > We need to support the scenario where a...

Personally I think a cleaner approach would be to by default use new "cake_migrations" table only. And activate the "legacy shim" with a feature flag `legacyTables` "true. Easy enough to...

# Plan of Attack: Consolidated Migration Tracking This is the last big piece of the new major coming up. Plays together well with new seed tracking: - cake_migrations - cake_seeds...

> Have you considered moving all the schema creation, query building logic into an abstraction that we can have multiple implementations for? That would let us capture the current behavior...

Cool! Lets please get those open PRs merged though, to avoid conflicts and allow me to start the sandbox showcases.

I like it. Is this repo still maintained? There wasnt any feedback so far on it.