Our project is currently running Rails 2.0, and I am concerned about the use of timestamps in migration file names in Rails 2.1. We use migrations a lot, for both table structure changes and application data changes, and it can happen that the order in which the migrations are run matters. Developers are required to update their area to get the latest changes before checking in, and it frequently happens that a migration file needs to be renamed prior to check in. But, that is okay, because it means that the developer wanting to check in the migration will first have to make sure (by running tests) that the renumbered migration will still work after the other migrations have been run. In this way, all the developers have to run the migrations in the same order.
In the new migration system with timestamps, rake db:migrate just runs whatever migrations haven't been run yet. If developer A checks in a migration, and then developer B does an update before checking in his migration, B will end up getting A's migration run after his (which might affect the outcome of the tests) and after developer A does an update, A will get B's migration run last. If the order matters, A's database will not be the same as B's, even though the areas of both will appear up to date.
This is not a good thing. Yes, conflicts in migration numbers are an annoyance, but they are an important annoyance, because they force you to make sure your changes are compatible with ones that are already checked in.
Is there a configuration option to turn this 2.1 feature off? --Paul
