rail 2.0 release estimate?

was there any talk at railsconf or any talk in the chat rooms about
rails 2.0 release. i seems they chose the new version number because
it won't be backwards compatible with 1.x sites.

There's no release date set. There will most likely be a round of RC
releases before 2.0 drops though.

What about the part of the question on whether the 2.0 release will be backwardly compatible with 1.x?

Actually, I think that the more interesting way to phrase that is whether 1.2.x will be forwardly compatible with 2.0?

I have a 1.1.6 and soon to be 1.2.2 site in production. (The 1.2.3 bugfix for ruby1.8.6 is probably going to replace 1.2.2 before it's really live.) I know that I'm occasionally tripped up by trying to use something from 1.2.x that doesn't exist in 1.1.6, but that hasn't yet overwhelmed my expectation of effort to move that application to 1.2.x. I know 1.2.x isn't backwardly compatible with 1.1.x and I wouldn't expect 1.(n+1).x to be with any 1.n.x. However, 1.n.x is typically going to work in 1.(n+1).0, but the effort move from 1.x (of anything) to 2.0 can be almost anything.

I haven't tracked Edge since the pre-1.1 days when I wanted to trade my hand-rolled polymorphic associations for a built-in implementation so I don't have a good foundation for building an expectation of the 1.2.x to 2.0 transition for an existing application.


Rob Biedenharn http://agileconsultingllc.com

And a 2.0.1 immediately after :wink:

It will definitely not be plug-compatible. There were many changes reported at RailsConf that would change how things work. There are warnings in 1.2.3 for at least some of them such as :class_name when defining associations. There were changes to the REST routing, soap web services are being moved to a plugin in favor of REST in the core, etc. You can always create an edge play area and do some of the porting early to reduce the impact.


If you just use :class_name without :foreign_key you get the message stating that in 2.0 they are changing the default from <class_name>_id to <association_name>_id.

The new default makes more sense than the old default, but for 1.2 they are recommending that you set it explicitly so it will not break when upgrading.