Version 2.0.0 has added a bad dependency to Rails 3.2.8.rc

[mhartl]

After being stable for months, jquery-rails 2.0.0 inexplicably added a dependency to the new Rails release candidate, 3.2.8.rc. This breaks the sample application for a bunch of Rails Tutorial readers, among others—anyone using 2.0.0 with Rails 3.2.x is probably affected. Version 2.0.2 works fine, and I've updated the tutorial's Gemfile accordingly, but this still seems worth fixing.

By the way, I'm genuinely curious to know how this happened. How could a previous version of a gem suddenly depend on an as-yet unreleased version of Rails?

[indirect]

Honestly, I have no idea. I can yank the 2.0.0 gem from rubygems.org, which sounds like it would fix things... work for you?

[indirect]

Oh... five minutes of research later, I know what's going on. 2.0.0 depends on railties "< 5.0, >= 3.2.0.beta". That means it will only attach to prerelease gems. The just-released 3.2.8.rc is the highest-numbered prerelease version of rails that is below 5.0, so that's what it gets. I think it was a mistake to release jquery-rails 2.0.0 depending on a prerelease version of rails, so I'm going to yank it.

@josevalim, @JangoSteve, plz to only add pre deps to pre releases of jquery-rails, k? thanks!

[mhartl]

Awesome. Thanks for being so quick with this. What will happen to existing applications that depend on jquery-rails 2.0.0?

[JangoSteve]

@indirect Agreed; this is the same reason I had to release v2.0.1 so quickly after v2.0 (due to a new dependency on railties 3.2.0.beta, for which I had to fix by merging a change to the non-beta version of 3.2.0). Please only make dependencies on beta or pre-release gems in beta or pre-release version numbers.

[indirect]

IIRC, bundles that are locked to 2.0.0 will now fail to install, and will need to be re-locked to a different version. That said, bundles locked to 2.0.0 must also be locked to a railties prerelease of 3.2, so I think those people have bigger problems. :)

On Aug 6, 2012, at 4:48 PM, Michael Hartl notifications@github.com wrote:

Awesome. Thanks for being so quick with this. What will happen to existing applications that depend on jquery-rails 2.0.0?

�
Reply to this email directly or view it on GitHub.

[mhartl]

Gotcha. Thanks again for the quick response.

[JangoSteve]

On the subject, I don't entirely understand why the minimum dependency was bumped to Rails 3.2; it's still compatible with 3.1. But oh well, we should be good now.

[indirect]

Weird... maybe we can drop it back down to 3.1 in a bugfix release? Since it's compatible...

On Aug 6, 2012, at 5:23 PM, Steve Schwartz wrote:

On the subject, I don't entirely understand why the minimum dependency was bumped to Rails 3.2; it's still compatible with 3.1. But oh well, we should be good now.

—
Reply to this email directly or view it on GitHub.

[JangoSteve]

I've got a few things to update in jquery-ujs, so i'll include this in the next minor version update.

[indirect]

Great, thanks Steve!

On Aug 6, 2012, at 5:36 PM, Steve Schwartz wrote:

I've got a few things to update in jquery-ujs, so i'll include this in the next minor version update.

—
Reply to this email directly or view it on GitHub.

[joerixaop]

Our jquery-rails was locked to 2.0.0, our railties was locked to 3.2.5, I don't see how yanking was necessary or even useful.
Unless I'm missing something only new projects that explicitly specified jquery-rails 2.0.0, but that, for some weird reason, did not specify the exact Rails version were broken. On the other hand, with the yanked gem deploying existing applications is suddenly not working anymore.

[indirect]

Any existing deployment or bundle that already has 2.0.0 installed will keep using it -- yanking 2.0.0 doesn't remove the gem from any place where it was already installed. Additionally, it was important to yank because any attempt to resolve a dependency graph that unlocked jquery-rails 2.0.0 would try Rails prerelease versions, which is very bad and could potentially update an application to a prerelease version of Rails unexpectedly. As in the OP's case. Which is why I yanked it.

[joerixaop]

Sure, if the gems were already installed things keep working. That assumes the gem was already installed on the machine a deployment is being done.
And a deployment (as opposed to starting a new project, or upgrading a gem) is the least attractive time to be encountering issues with bundler. I don't want to be forced to upgrade the gem at the last moment (yesterday installing an a clean server worked, today it doesn't, which is the only reason I even know about this gem being yanked), I don't want to change our deployment scripts at the last moment, I definitely don't want to start installing stuff manually.

To be honest, this is partly a problem with rubygems, it should have some way to distinguish between: this gem has been yanked because of a gemspec issue vs. this gem has been yanked because of a security issue. But notice that rails for example doesn't actually yank versions even if they have security issues (as the 3.2.5 version that we have in our Gemfile), after all, not every application is deployed to the internet at large, nor does every application necessarily use a feature that causes the security problem.

[indirect]

@joerixaop, I'm a little unclear on how yanking the jquery-rails gem causes "issues with Bundler". It certainly causes issues with your ability to deploy to new boxes... but so would connectivity issues to rubygems.org. I'm (apparently) not as conservative as rails-core is, and I think gems that are broken should be yanked so that the brokenness can't spread. Since this gem happens to be mine, I yanked the broken version as soon as I realized it was broken.

If you're in a situation where you need control over your gems, please use either 1) Bundler's pack command and the vendor/cache directory or 2) your own internally maintained gem server. That way situations like this one (or even rubygems.org going down) will not effect your deploys.