Skip to content

Fix #37: Lock Listen to less than 3.1. #38

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Apr 25, 2016
Merged

Fix #37: Lock Listen to less than 3.1. #38

merged 2 commits into from
Apr 25, 2016

Conversation

envygeeks
Copy link
Contributor

Jekyll supports 2.1+ but @e2 has made it so that Listen only supports
2.2 so this locks it so that we are on a version of Listen that we can
actually support since we still support all supporte Ruby versions.

Jekyll supports 2.1+ but @e2 has made it so that Listen only supports
2.2 so this locks it so that we are on a version of Listen that we can
actually support since we still support all supporte Ruby versions.
@@ -13,7 +13,7 @@ Gem::Specification.new do |spec|
spec.executables = spec.files.grep(%r{^bin/}) { |f| File.basename(f) }
spec.require_paths = ["lib"]

spec.add_runtime_dependency "listen", "~> 3.0"
spec.add_runtime_dependency "listen", "~> 3.0", "< 3.1"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, I'm afraid we'll never remember to remove this constraint. Should we add a comment describing when it can be released, like # Remove < 3.1 constraint when we drop support for Ruby 2.0?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually thought about that! How about: "XXX: Remove with Jekyll 4 or in 2017 when 2.1 goes EOL"?

@parkr
Copy link
Member

parkr commented Apr 25, 2016

👍 Thanks!

@jekyllbot: merge +bug

@jekyllbot jekyllbot merged commit 27cc771 into jekyll:master Apr 25, 2016
jekyllbot added a commit that referenced this pull request Apr 25, 2016
@e2
Copy link
Contributor

e2 commented Apr 26, 2016

Guys, this is a bit dangerous (locking):

If you stick to Listen 3.0.x, and someone accepts a Ruby 2.2.x-only patch into a 3.0.x version of Listen (there are no safety checks for this ATM!), things will break for your users in PRODUCTION! (If they upgrade with the lock in place).

If there's any line of code which is Ruby 2.2.x specific that doesn't have coverage (or has a different behavior), users with Ruby 2.1 using Listen 3.0.x (with a backported patch like that) will experience a crash.

This is unlikely, but technically, that's what's going on.

Not to mention: everyone locked to 3.0.x is now stuck without having any new patches or updates. (Unless backported).

The best solution is to release a version of jekyll-watch that is Ruby '~> 2.2' only.

That's because users with Ruby 2.2 should have a choice of using Listen 3.1.x. By locking, you've taken that choice away. (Ironically, Ruby 2.2. users would have to lock to an earlier version of jekyll-watch - just in order to upgrade past Listen >= 3.1 for bugfixes).

Summary:

By locking, you're doing 2 "bad" things:

  1. Exposing users to problematic crashes in production (the fact that Listen 3.0.x works is actually "a bad thing" - it's a hidden potential problem).
  2. Not letting them upgrade Listen

Moral: all because it looks like it works, doesn't mean it's supposed to.

@jekyll jekyll locked and limited conversation to collaborators Apr 23, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants