Every application that gets coded by more then one person has benefit with timestamped migrations. I think most Rails applications get developed by > 1 person, so timestamped migrations are the logical choice imo.
regards, Jan De Poorter http://workswithruby.com On 11 Jul 2008, at 16:11, Andrew Stone wrote: > > > On Fri, Jul 11, 2008 at 9:54 AM, Michael Koziarski <[EMAIL PROTECTED] > > wrote: > > > If you don't mind, could you explain why the should be the > default? Or is > > this explanation already out there on a blog or something, I'm > obviously > > missing something because I don't get that reasoning. > > For all the reasons it was included in the first place, fewer > conflicts on branches, etc. But most importantly, we don't want to > change this behaviour back in a minor point release. Those who want > to switch to integers again can do so easily enough, and we keep the > timestamps for people who need them. > > > I'm not familiar with what the "etc" represents and find it funny > you mention "Those who want to switch to integers again can do so > easily enough". When those who wanted timestamps could have done it > easily enough without it being forced upon those who don't. > > You guys made the logical push of removing features from core that > were "edge use cases" to plugins but then pulled a plugin into core > and made the standard, without an option. That is quite confusing. > > I understand the notion of "convention over configuration" and > "opinionated software" but this is a step beyond. > > -- > Andrew Stone > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---