ffi-1.11.0

[maximilientyc]

Hey,

ffi-1.11.0 has been removed from rubygems: https://rubygems.org/gems/ffi/versions.

Your bundle is locked to ffi (1.11.0), but that version could not be found in any of the sources listed in your Gemfile. If you haven't changed sources, that means the author of ffi
(1.11.0) has removed it. You'll need to update your bundle to a version other than ffi (1.11.0) that hasn't been removed in order to install.

Is there any explanation for that? Should we update to ffi-1.11.1?

Thanks

[eregon]

See #700 (comment)

In general, it's very disruptive to yank a gem, but in this case if it allows Bundler to resolve correctly then I guess it's worth it.

[dogweather]

Yeah, I'm a little skeptical about this solution. I think I would have voted for advising people who still use Ruby 1.9 to add a gemfile entry specifying ffi 1.10.0. (If I understand it correctly, that would work.)

Instead, we're breaking deploys and builds for an untold number of Ruby apps.

[eregon]

@dogweather

Instead, we're breaking deploys and builds for an untold number of Ruby apps.

I'm trying to understand. Only people who updated from 1.10.0 to 1.11.0 should be affected.
So if they updated in the last 5 days to 1.11.0, why would they not also update to 1.11.1 ?
It's a manual process and breaking previously-working builds for Ruby >= 2.0 users, so I can understand the frustration though.

Maybe we should have the ability to only "yank" from the index in RubyGems, but not remove the existing released .gem file. That would be something to ask on the RubyGems tracker though.

[DannyBen]

For what its worth - I was affected and spent about an hour trying to figure out why.

• I recently did bundle update, without paying much attention to what was updated. I did this when 1.11.0 was alive.
• Today I updated something minor in the code, and tests failed on Travis, showing they "cannot find ffi"
• Since Travis recently had severe connectivity issues, I thought this was back in play - so I almost blamed Travis for it.
• I only then went to look if there is indeed a problem with ffi 1.11.0, and then the fix was obvious.

Still - it was a waste of time.

In my opinion, yanking a gem should be reserved only to severe cases - like catastrophic security vulnerability - or in cases where a fixed version is deployed very shortly after the yank candidate was deployed. Short as in hours, not days - before anyone had any real chance of downloading it, and forgetting they did.

No harm done, but sounds like not yanking would have made less of an impact to people using ancient Ruby versions.

[dogweather]

So if they updated in the last 5 days to 1.11.0, why would they not also update to 1.11.1 ?

People with production apps don't update daily. It's a carefully controlled process. Fixing it is non-obvious because this is very exceptional behavior and there's no public announcement about the yank.

[dogweather]

In my opinion, yanking a gem should be reserved only to severe cases - like catastrophic security vulnerability

Yep --- that's the implication. Then add to the confusion that there's nothing in the changelogs about this, or some kind of announcement. The linked comment on another issue only indirectly describes the situation.

[larskanis]

Maybe we should have the ability to only "yank" from the index in RubyGems, but not remove the existing released .gem file.

That was how yank was implemented in the past. However the situation has changed, so that the gem is removed entirely leading to broken deployments now: https://blog.rubygems.org/2015/04/13/permadelete-on-yank.html

Unfortunately I didn't know about this policy change. So sorry for the inconvenience! I added a notice to the CHANGELOG.

[agraves]

If you're coming here because you blew away your gem cache and now things won't deploy, just hand-edit your Gemfile.lock from ffi (1.11.0) to ffi (1.11.1) (and preserve leading whitespace just to be safe).