Soft-yanking

[pirj]

Problem

Occasionally, when maintainers publish new gem versions, they make mistakes.

Examples:

1. rails Ruby version constraint mistake that broke 5.2.4.3-5.2.4.5 on Ruby 2.2. See https://github.com/rails/rails/blob/v5.2.4.3/activesupport/lib/active_support/cache/redis_cache_store.rb#L323
   It has been fixed in May 2020, but only released nearly a year later in Rails 5.2.4.6 (May 2021).

2. rspec-rails Ruby version constraint mistake that broke rspec-rails on Ruby 2.2.

3. diff-lcs issue with older Ruby versions

4. cucumber 4.0.0 broke compatibility due to diff-lcs dependency, fixed in 4.0.1 by pinning diff-lcs version to ~> 1.3.

Suggestion: Soft-yank

What soft-yanking means?

Gem maintainer scenario

The maintainer can soft-yank a gem version, just like they can yank it:

gem soft-yank GEM -v VERSION [-p PLATFORM] [--key KEY_NAME] [--host HOST]

Server/CI scenario

It remains possible to install the soft-yanked version of a gem with bundle install from Gemfile.lock.
Bundler emits a warning.

Developer scenario

Bundler excludes soft-yanked versions from dependency resolution.
bundle update/bundle lock show an error, just like for a yanked gem version or a removed gem.

Could things have gone better?

rspec-rails 4.0.0 could have been soft-yanked.
cucumber 4.0.0 could have been soft-yanked.
diff-lcs 1.4.3 could have been soft-yanked.

I have no such certainty regarding Rails, since it took a year to release the fix.

Misc

Related: rubygems/rubygems#1506 (comment)

#26 is semi-related, a proposal to prevent the only cause I'm practically aware of, weak Ruby version constraint. There might be others, like adding extra runtime dependencies, but I have not seen this in the wild.

cc @halostatue @JonRowe @marcandre @mattwynne @aslakhellesoy.

[simi]

🤔 It seems majority of examples are related to old EOL Ruby. I suggest to upgrade instead looking for bandaid.

[marcandre]

Sounds to me like a good idea. It's not clear to me what the advantages of "hard-yanking" over this.

[pirj]

suggest to upgrade

For the user standpoint? Practically, it's often easier said than done. See e.g. GitLab 2.5.3 -> 2.6.3.

From maintainers' standpoint?
rspec supports Ruby down to 1.8.7 until now in version 3.x. For ten years after Ruby 1.8.7 EOL.
rspec will keep supporting Ruby 2.3 that is EOL for 2.5 years now in the upcoming 4.0, for probably another five years until RSpec 5.0.
rails 5.2.0 was released on April 09, 2018 supported Ruby >= 2.2.2, and Ruby 2.2 EOL on 31 Mar 2018. The last of the 5.2.x to date, 5.2.6, was released May 05, 2021.
I believe they have their reasons to support users that stick with older Ruby versions.

[simi]

@pirj gem support isn't relevant at all. Related Ruby itself is not supported anymore and you should not use it.

🤔 If I remember well, yank of gem is recommended to be done only under some circumstances (for example when you include some secrets as part of the gem bundle by mistake). If you just release broken version, you can fix it by releasing another one.

Can you explain on your examples why releasing new version isn't enough to fix the problem and how soft-yanking would solve the problem instead?

[pirj]

the advantages of "hard-yanking" over this

Hard-yanking should stay for cases like

• mistakenly introduced severe security vulnerabilities or bugs that could irreversibly corrupt data [1]
• hijacking

IANAL, but probably not for licensing issues.

[pirj]

Can you explain on your examples why releasing new version isn't enough to fix the problem

Easy.

# Gemfile
gem 'rspec-rails'

Releasing rspec-rails 4.0.1 didn't help because bundle was still resolving 4.0.0 as a matching version for Ruby 2.2.

See the link from the description for details.

[simi]

Releasing rspec-rails 4.0.1 didn't help because bundle was still resolving 4.0.0 as a matching version for Ruby 2.2.

And and wouldn't be locking to minor version enough for you in this case?

# Gemfile
gem 'rspec-rails', '~> 3.9'

[pirj]

You got straight to the point.
One gem soft-yank rspec-rails -v 4.0.0 command issued by one gem maintainer vs thousands of projects having to specify version constraints in their Gemfiles.

[simi]

@pirj that's from your point of view. Another projects will get into trouble even they don't care in this case getting (and also potentially reporting) annoying warning. And since in your case the reason is EOL Ruby, I think maintainer should prefer comfort for officially supported Ruby versions and this this is not valid reason for any kind of yank (even soft) IMHO.

[pirj]

I apologize for making this point, but I'm speaking not just as a developer of a project who is too lazy to update Ruby version, but as one of RSpec maintainers.

[marcandre]

@pirj that's from your point of view. Another projects will get into trouble even they don't care in this case getting (and also potentially reporting) annoying warning.

My understanding is that the warning would only occur for anyone who happened to have locked on the 4.0.0 version. It would disappear as soon as they follow instructions, which would install the correct version.

Any other users would have the correct version installed (i.e. the latest 3.x.x or 4.0.1 depending on their set).

[simi]

@marcandre according to

Server/CI scenario
It remains possible to install the soft-yanked version of a gem with bundle install from Gemfile.lock.
Bundler emits a warning.

Developer scenario
Bundler excludes soft-yanked versions from dependency resolution.
bundle update/bundle lock show an error, just like for a yanked gem version or a removed gem.

I assumed anyone using soft-yanked version will get warning or error.

@pirj no need to apologise, I'm just sharing my ideas and trying to find out potential problems to discuss.

[pirj]

the advantages of "hard-yanking" over this

Speaking of hard-yanking, I stick to the belief this should be reserved exclusively to the scenario when this is coordinated with the RubyGems team.
Otherwise, someone in the bad mood can ruin the day of on-call engineers of many projects, who will spend their evenings trying to understand why their container clusters lost the ability to scale dynamically.

But it's an off-topic, better suited for rubygems/rubygems#1506 or another RFC.

[marcandre]

I assumed anyone using soft-yanked version will get warning or error.

Right. To use a soft-yanked version you must have done a gem install before it was soft-yanked and thus got it in your Gemfile.lock though. bundle update would resolve the warning too.

[simi]

You got straight to the point. One gem soft-yank rspec-rails -v 4.0.0 command issued by one gem maintainer vs thousands of projects having to specify version constraints in their Gemfiles.

🤔 Also getting back to this solution. Wouldn't be enough to release 4.0.0.1 version, same as the 4.0.0 just doing Ruby version check in runtime and raising friendly error to lock to ~> 3.9 for old rubies? That way this problem can be fixed by bundle update and following printed instructions (non-locked bundle install will work by default).