Version 2.0.0 has added a bad dependency to Rails 3.2.8.rc about jquery-rails HOT 14 CLOSED

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?

from jquery-rails.

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!

from jquery-rails.

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

from jquery-rails.

@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.

from jquery-rails.

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 [email protected] 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.

from jquery-rails.

Gotcha. Thanks again for the quick response.

from jquery-rails.

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.

from jquery-rails.

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.

from jquery-rails.

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

from jquery-rails.

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.

from jquery-rails.

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.

from jquery-rails.

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.

from jquery-rails.

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.

from jquery-rails.

@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.

from jquery-rails.