Can't upgrade to 4 beta 1

I had to update several gems for Bundler to accept it but now I'm stuck:

bundle update rails devise knockoutjs-rails sass-rails coffee-rails devise-encryptable oojs
Fetching gem metadata from https://rubygems.org/
Fetching gem metadata from https://rubygems.org/
Resolving dependencies…
Bundler could not find compatible versions for gem "railties":
   In Gemfile:
     coffee-rails (~> 3.2.1) java depends on
       railties (~> 3.2.0.beta) java

     railties (4.0.0.beta1)

I try to support both MRI and JRuby in my application but they should be independent from each other, right? I mean, I can't run Bundler for both at the same time.

What am I supposed to do in this situation?

Indeed https://github.com/rails/rails/issues/9386

Francesco Rodríguez

@frodsan (http://twitter.com/#!/frodsan)
https://github.com/frodsan
http://www.frodsan.com/

I manually remove those java-related dependencies from Gemfile.lock
and tried again. After a few iterations I got stuck on this now:

bundle update rails devise knockoutjs-rails sass-rails coffee-rails

devise-encryptable oojs railties common-dialogs
Fetching gem metadata from …
Fetching gem metadata from …
Resolving dependencies…
Bundler could not find compatible versions for gem “railties”:
In Gemfile:
devise-encryptable (>= 0) ruby depends on
railties (~> 3.1) ruby
sass-rails (~> 4.0.0.beta1) ruby depends on
railties (4.0.0.beta1)
But I don’t understand since devise-encryptable depends only on
devise >= 2.1.0:

In case it helps, I’m running on Ruby 2.0.0-p1 installed with latest
RVM.

Rodrigo, rails-core is more for discussion about features. If you're
still struggling, please file an Issue and I"ll help you over there.

Thanks, Steve.

I could finally upgrade my Rails application and I must say it is

much faster on Ruby 2 + Rails 4 beta 1 and it wasn’t a painful
process either. I just found a few bugs that I was able to
work-around:

https://github.com/rails/rails/issues/9449

For the bug above I just had to reorder some routes until it is

fixed on master.

I've experienced another bug that I haven't created a issue for

because I can’t reproduce it. For some reasons, some CSS image-url
paths were being generated incorrectly missing the leading “/assets”
and rendering as “/fields/…” instead of “/assets/fields/…”. I
somewhat added a new rule to the SCSS class to add some
“background-image: image-path(‘fields/…’)” and then all url paths
have been fixed. Then I removed the newly inserted line so that the
file was exactly like the original one and the CSS kept rendered
correctly. Sorry, I have no idea why that happened but it happened
multiple times to assets in different gems.

The Ruby part was the easiest in the upgrade process. I had to

upgrade lots of gems and use ‘devise’ from the ‘rails4’ branch, fix
the dependency for my own rails-sandbox-assets gem and release it,
fork knockoutjs-rails and fix it:

https://github.com/jswanner/knockoutjs-rails/pull/3

My Ruby specs only failed due to some config changes in

config/environment**/*.rb. I created a new Rails app and based the
new configs on the new generated one. After that my Ruby specs all
passed without any modification. Sadly that wasn’t the case for my
JavaScript specs…

Certainly the most time consuming task was to port my client-side

code to jQuery 1.9. It is a bit sad that Rails 4 will force you to
upgrade jQuery if you’re using jquery-rails, but that’s ok. At least
most of my client-side code is in the Grails application of the
overall application I maintain. I’ll have more time to upgrade to
jQuery 1.9 for most of the scripts :slight_smile:

Thank you very much for this release. I'm not sure if it is due to

Ruby 2, Rails 4, or both, but my feeling is that the application is
responding much faster, at least in development mode.

Unfortunately I can't deploy it on Ruby 2 yet because there is a bug

that will prevent me to use the bson_ext gem in Ruby 2.0.0-p1. For
some reason it generates a “ext/bson_ext/bson_ext” instead of
“ext/bson_ext/cbson.so” (although a diff will reveal they’re the
same file) like it is the case for Ruby 1.9.3. But for development
mode, that is ok to use Ruby 2 as it will fallback to the Ruby
implementation that isn’t that slow, at least, for development
purposes.

Cheers,

Rodrigo.