My fork was referenced a couple of times. I don't feel strong about
this implemetation. It was just the easiest thing I found to work
and got it done. I'm sure I missed a couple of issues. (Although I'm
actually already using it.)
The only issue I've found was the one previously mentioned about
plugins having clashing migrations not being handled and also that
it's a little behind James' master (e.g. exception notification issue).
I feel strong about Engine migrations being as much aligned to Rails
migrations as possible. Not so much for technical reasons (clashes
aren't that likely, although still can occur etc.) but more for
reasons like "framework usability" and education. I really don't
want to wrapp my head around wondering how Engine migrations behave
different from Rails migrations on certain edge cases. And I don't
want to explain it. It's hard enough for me to remember how Rails
migrations work with certain conditions given. So, from my point of
view that would be the most important goal: having Engines
migrations transparently work exactly how Rails migrations work.
I personally don't care too much about backwards compat in this
case. I'd implement things in a way that is "done the right way" for
Rails 2.1+ and on top of that maybe have a rake task or whatever
tool to update migrations from old apps.
With a few tweaks, yours/Samuel's versions will work as Rails does AND
be backwards compatible, win-win?
If we want to support numbered migrations (as Rails still does)
tracking migrations per plugin (in an extra table) is necessary.
This is the bit that will need fixing, and then a rake task to upgrade
older projects.
Tekin
_______________________________________________
Engine-Developers mailing list
[email protected]
http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org
