现在Rails已经有timestamped migrations个版本了，位于/db/schema.rb顶部的单个版本号似乎没有意义.有时，在处理多个开发人员或多个分支时，版本号最终会不正确.
Rails现在还使用那个:version参数吗？
它不正确有什么害处吗(比如:它不反映最近应用的提交的时间戳)？
示例:
ActiveRecord::Schema.define(:version => 20100417022947) do
# schema definition ...
end
实际上，版本比这重要得多.您引用的代码实际上只是Asmise_Migrated_Upto_Version功能的一小部分.迁移版本的实际效果是all prior migrations(as found in the db/migrate directory)are assumed to have been run.(因此，是的，它做的正如函数名称所暗示的那样).
这有一些有趣的含义，特别是在多人同时进行新迁移的情况下.
如果按照Rails团队的建议设置schema.rb的版本，就可以了.您百分之百保证会有冲突(模式版本)，提交/合并用户必须通过合并他们的更改并将:version设置为两个版本中最高的一个来解决它.希望他们这样做是正确的.
一些项目 Select 将schema.rb排除在版本控制之外，以避免这种持续的冲突问题.他们可能只依赖于迁移，或者保留一个单独的、受版本控制的模式副本，他们偶尔会更新该副本.
如果有人使用时间戳prior创建到您的schema.rb:version的迁移，就会出现问题.如果您使用db:Migrate，您将应用他们的迁移，您的schema.rb将会更新(但会保留相同的、更高的:version)，一切都会很好.但是，如果您碰巧使用了db:schema:load(或db:Reset)，那么您不仅会错过它们的迁移，还会错过assume_migrated_upto_version will mark their migration as having been applied.
此时最好的解决方案可能是要求用户将他们的迁移重新加时间戳到他们合并的时间.
理想情况下，我更希望schema.rb实际包含应用的迁移编号列表，而不是假定为-to-to-here:version.但我怀疑这是否会发生--Rails团队似乎认为通过签入schema.rb文件就可以充分解决问题.