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.
Vit
How does that work? Do we need a volunteer to get it into Fedora? I have an RPM'd gem I would like to submit.
========= Tyler Smart Check out the IT.rb group: https://docspace.corp.redhat.com/groups/itrb
----- Original Message ----- From: "Vít Ondruch" vondruch@redhat.com To: "Ruby SIG mailing list" ruby-sig@lists.fedoraproject.org Sent: Tuesday, June 14, 2011 2:06:23 AM Subject: Rails 3.1 for F16
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.
Vit _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
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
Dne 15.6.2011 19:28, Mo Morsi napsal(a):
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).
From my POV, if they did not migrated to Rails 3 yet, then holding back with upgrade to Rails 3.1 doesn't have sense. Also, I believe that you should be able to install the F15 Rails on F16 if you like the older version. If updating, why not the bleeding edge? Updating to 3.0.x version doesn't bring anything new.
Vit
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
On 06/16/2011 03:20 AM, Vít Ondruch wrote:
Dne 15.6.2011 19:28, Mo Morsi napsal(a):
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).
From my POV, if they did not migrated to Rails 3 yet, then holding back with upgrade to Rails 3.1 doesn't have sense. Also, I believe that you should be able to install the F15 Rails on F16 if you like the older version. If updating, why not the bleeding edge? Updating to 3.0.x version doesn't bring anything new.
Vit
Hrm good point, not sure if people will update to 3.0 or 3.1. All the upstream hubbub has been about migrating to rails 3.0. If we see more adoption of 3.1 instead going here on forward then yes I fully support moving to 3.1 at a future Fedora version.
We can't satisfy everyone (afterall thats what gem and rvm is for) but I think we maximize our chances of making Fedora a popular platform for Ruby developers if we can stay in sync w/ the perceived most common use case / supported stack in the Ruby / Rails community.
In any case I agree it wouldn't hurt to start prepping the rpms, then we can make the decision on which Fedora version to push those into when we have more information.
-Mo
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@redhat.com To: ruby-sig@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig@lists.fedoraproject.org