-
Notifications
You must be signed in to change notification settings - Fork 481
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
fix lumberjack version runtime dependency #882
Conversation
guard.gemspec
Outdated
@@ -19,7 +19,7 @@ Gem::Specification.new do |s| | |||
s.add_runtime_dependency "thor", ">= 0.18.1" | |||
s.add_runtime_dependency "listen", ">= 2.7", "< 4.0" | |||
s.add_runtime_dependency "pry", ">= 0.9.12" | |||
s.add_runtime_dependency "lumberjack", "~> 1.0" | |||
s.add_runtime_dependency "lumberjack", ">= 1.0.11", "< 1.1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should probably be < 2.0
instead of < 1.1
. No need to lock it in so specific.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@noraj1337 Thanks but I don't see the point of this change: the dependency already allows you to use 1.0.11
, and allows you to use future 1.x
versions, see http://guides.rubygems.org/patterns/#pessimistic-version-constraint.
We could change the dependency to ~> 1.0.11
but that would unnecessarily restrict the allowed version of lumberjack
to >= 1.0.11, < 1.1
(exactly the same as you've done here).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So ">= 1.0.11", "< 2.0"
is better. Or may be a less strict ">= 1.0.11"
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So ">= 1.0.11", "< 2.0" is better. Or may be a less strict ">= 1.0.11".
If we want to go forward, and I actually think it's ok in this case, let's do ">= 1.0.12", "< 2.0"
!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or even just ">= 1.0.12"
, let's be optimistic. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rymai Why 1.0.12 and not 1.0.11 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why 1.0.12 and not 1.0.11 ?
Because that's the latest version. Just to be clear once again: it's not the job of Guard to fix the "Fixnum" warnings, Guard's current dependency on lumberjack allows the use of the fixed version of lumberjack (1.0.11
) so in theory, from a semver perspective, there's nothing to change.
Imagine a project that's using the latest Guard, lumberjack 1.0.10
and Ruby 2.3: no "Fixnum" warning so there's nothing to change in Guard.
Imagine also a project that's using the latest Guard, lumberjack 1.0.12
(because they bundle update lumberjack
) and Ruby 2.4: no "Fixnum" warning so there's nothing to change in Guard.
That being said, I'm ok updating the dependency in this case because:
- lumberjack is very stable (not a lot of new releases)
- it's very likely that projects that depend on it are already using the latest version
- it will "fix" the "Fixnum" warning for Ruby 2.4 users (even though it's not Guard's job)
- it's still compatible with older Rubies
- it's good to move forward
Since the dependency upgrade is not needed per se, we can just do ">= 1.0.12"
, there's no need to use ">= 1.0.11"
.
Does that make sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If no need for backward compatibility that seems ok.
@noraj1337 Thanks! |
#863