On 06/14/2011 02:06 AM, Vít Ondruch wrote: Hrm the stable rails 3.1 version is expected to be released in a little over a week unless there are any setbacks [1] Here's the thing, I feel that most upstream communities are slowly pushing towards migrating from Rails 2.3.x to 3.0.x. I have heard almost nothing about Rails 3.1.x in production as of now (as is expected since it hasn't been released). So it might make sense to hold off on the update to 3.1 until we see more upstream projects starting to adopt it and give feedback. Of course we can always go the 'bleeding edge' route to be able to say we are one of the first platforms to perform that update, but we already can say that with our current Rails 3.0.x stack, and it might make sense to stabilize around that a bit before updating further. Of course if there are no incompatibilities, this probably won't be a big deal, but I'm not sure if this is the case (the Rails community does seem to be getting better at this). Again things also may only be discovered as more upstream users start using Rails 3.1 in their own projects. Looking at the changelogs [2][3][4][5][6], there are things that at first glance could lead to issues: * ActiveSupport::Dependencies now raises NameError if it finds an existing constant in load_missing_constant. * PostgreSQL adapter only supports PostgreSQL version 8.2 and higher. * It is prohibited to perform a in-place SafeBuffer mutation (actionpack) * Rely on Rack::Session stores API for more compatibility across the Ruby world. This is backwards incompatible since Rack::Session expects #get_session to accept 4 arguments and requires #destroy_session instead of simply #destroy. (actionpack) * The default format has been changed to JSON for all requests. If you want to continue to use XML you will need to set `self.format = :xml` in the class (activeresource) * jQuery is no longer vendored, it is provided from now on by the jquery-rails gem. (railties) Some of these may not be an issue, but others warrant looking into before we update. -Mo [1] http://weblog.rubyonrails.org/2011/6/9/ann-rails-3-1-0-rc4-has-been-released [2] https://github.com/rails/rails/blob/master/activesupport/CHANGELOG [3] https://github.com/rails/rails/blob/master/activerecord/CHANGELOG [4] https://github.com/rails/rails/blob/master/actionpack/CHANGELOG [5] https://github.com/rails/rails/blob/master/activeresource/CHANGELOG [6] https://github.com/rails/rails/blob/master/railties/CHANGELOG

I agree with this, moving to Rails 3.0.X would be a much better move and maybe F17 can be 3.1. ========= Tyler Smart Check out the IT.rb group: https://docspace.corp.redhat.com/groups/itrb ----- Original Message ----- From: "Mo Morsi" <mmorsi(a)redhat.com&gt; To: ruby-sig(a)lists.fedoraproject.org Sent: Wednesday, June 15, 2011 1:28:40 PM Subject: Re: Rails 3.1 for F16 On 06/14/2011 02:06 AM, Vít Ondruch wrote: We should probably submit Rails 3.1 as a feature for F16. Any volunteer? I am volunteering to do the packaging as soon as the stable version gets released. Hrm the stable rails 3.1 version is expected to be released in a little over a week unless there are any setbacks [1] Here's the thing, I feel that most upstream communities are slowly pushing towards migrating from Rails 2.3.x to 3.0.x. I have heard almost nothing about Rails 3.1.x in production as of now (as is expected since it hasn't been released). So it might make sense to hold off on the update to 3.1 until we see more upstream projects starting to adopt it and give feedback. Of course we can always go the 'bleeding edge' route to be able to say we are one of the first platforms to perform that update, but we already can say that with our current Rails 3.0.x stack, and it might make sense to stabilize around that a bit before updating further. Of course if there are no incompatibilities, this probably won't be a big deal, but I'm not sure if this is the case (the Rails community does seem to be getting better at this). Again things also may only be discovered as more upstream users start using Rails 3.1 in their own projects. Looking at the changelogs [2][3][4][5][6], there are things that at first glance could lead to issues: * ActiveSupport::Dependencies now raises NameError if it finds an existing constant in load_missing_constant. * PostgreSQL adapter only supports PostgreSQL version 8.2 and higher. * It is prohibited to perform a in-place SafeBuffer mutation (actionpack) * Rely on Rack::Session stores API for more compatibility across the Ruby world. This is backwards incompatible since Rack::Session expects #get_session to accept 4 arguments and requires #destroy_session instead of simply #destroy. (actionpack) * The default format has been changed to JSON for all requests. If you want to continue to use XML you will need to set `self.format = :xml` in the class (activeresource) * jQuery is no longer vendored, it is provided from now on by the jquery-rails gem. (railties) Some of these may not be an issue, but others warrant looking into before we update. -Mo [1] http://weblog.rubyonrails.org/2011/6/9/ann-rails-3-1-0-rc4-has-been-released [2] https://github.com/rails/rails/blob/master/activesupport/CHANGELOG [3] https://github.com/rails/rails/blob/master/activerecord/CHANGELOG [4] https://github.com/rails/rails/blob/master/actionpack/CHANGELOG [5] https://github.com/rails/rails/blob/master/activeresource/CHANGELOG [6] https://github.com/rails/rails/blob/master/railties/CHANGELOG _______________________________________________ ruby-sig mailing list ruby-sig(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig