Jonathan Rochkind's Profile

It's because the semantics don't work quite right. Migrations these days are timestamped, so you can roll back and forward in the order the migrations were applied, right? The timestamp is encoded in the migration file name.

If you just use migrations from the engine... they'll be timestamped with the time the developer of the engine created them, not the time your app actually first included/applied them.

The best thing I've found to do is have a generator which generates your engine/gem's migrations directly into the local rails app, with a filename with timestamp based on time-of-generation-into-local-app, and only doing this generation if a migration with the same name (not counting timestamp) does not already exist in local app (so the generation step is idempotent, and can be run for later versions of engine/gem and only add new migrations, not duplicate ones already generated).