Jumping in on the migration issue, this also happens with customized "products" We sell a package to a customer that requires customer specific modifications to the database. The core product continues development. At some point in the future the customer requests a change/improvment that is in the core product. We want to remerge to core to the customer -- yes as DHH mentioned this is an infrequent integration issue, but it happens often enough in practice to be a concern (if you sell products and not services).
One solution would be to allow local migrations, tied to existing migrations -- possibly in like named subdirectories? We would still have the concept of individual version numbers, but also support minor version numbers (the default being the most recent?) if I migrate to version 4 I know all local modifications are in place as well. The version table would need a second column to store the local minor version number. This opens a door migration failures (a local migration adds a column that is later added in "trunk" migration), but would certainly provide value for us. Would a patch providing this functionality be accepted? Additional levels could be argued, but would be more complex than I have encountered in practice. pth _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
