This repository has been archived by the owner on Apr 14, 2021. It is now read-only.
outdated shouldn't say "Bundle up to date!" if results are just filtered out. #5076
Comments
|
... just not sure what it should say. Maybe "No %{level} updates available" or somesuch. |
chrismo
added a commit
to chrismo/bundler
that referenced
this issue
Oct 13, 2016
Fixes rubygems#5076. When a filter option is in use and it filters out everything in the requested categories, it's safer to say there were no %{level} updates to display rather than "Bundle up to date!" Tracking an additional local variable with the exact info to know that even when filtered there was nothing to update anyway I didn't feel was worth it with the current design.
sounds reasonable to me |
|
good - that's what i went with :) you can review on #5061. |
homu
added a commit
that referenced
this issue
Oct 19, 2016
Conservative updates on outdated Add conservative resolving behavior to outdated command. - [x] convert existing flags to --filter-* - [x] deal with strict flag - [x] make a 2.0 issue to consider making strict flags more consistent - [x] fix #5065 (outdated filter options don't work with `--strict') - [x] fix #5076 (outdated shouldn't say "Bundle up to date!" if results are just filtered out.) - [ ] document breaking change reasons? (_commit comment has something at least now_) - [x] what about `bundle show --outdated`? (_it's a much simpler version ... prolly just going to leave it alone for now?_) The flags as passed to the GemVersionPromoter _change_ resolution. <=1.13.2 of bundle outdated, those flags merely filter the output, with no influence on resolution. If the lockfile is set to foo 1.0.0, and all of the following exist: 1.0.1, 1.1.0, 2.0.0, then <=1.13.2 bundle outdated currently will show: `foo (newest 2.0.0, installed 1.0.0)` <=1.13.2 `bundle outdated --minor` simply filters away that line and won't show it. With these changes, `bundle outdated --minor` would be fed to the GemVersionPromoter and actually only resolve `foo` up to `1.1.0`. This gist shows how it currently works, filtering the output: https://gist.github.com/chrismo/0bc6cfa00f539787101a9a2c900616d3 It's unfortunate timing. They were only added in 1.12 ... I'm biased, but feel like the affect the flags have on resolution is of greater value, and would be better to keep in sync with how they work fed to the `bundle update` command as of 1.13, and we could add new --filter-patch flags to replace what they do currently. IIRC, there was some confusion at the time that Andre perhaps even thought these flags as of 1.12 would be affecting what the newest would resolve to, instead of just filtering the output, so - _if_ I'm remembering correctly, that's also influencing my opinion. But, I can be swayed by the breaking behavior argument. from @indirect in [this comment](#4841 (comment)): "IMO, this is what we were trying to do in 1.12, and failed to do because resolving is complicated. :/ I would be okay with this change on the grounds that the previous flags were documented so it sounded like they cause the new resolver aware behavior. 👍"
chrismo
added a commit
to chrismo/bundler
that referenced
this issue
Oct 19, 2016
Fixes rubygems#5076. When a filter option is in use and it filters out everything in the requested categories, it's safer to say there were no %{level} updates to display rather than "Bundle up to date!" Tracking an additional local variable with the exact info to know that even when filtered there was nothing to update anyway I didn't feel was worth it with the current design.
homu
added a commit
that referenced
this issue
Oct 21, 2016
Conservative updates on outdated Add conservative resolving behavior to outdated command. - [x] convert existing flags to --filter-* - [x] deal with strict flag - [x] make a 2.0 issue to consider making strict flags more consistent - [x] fix #5065 (outdated filter options don't work with `--strict') - [x] fix #5076 (outdated shouldn't say "Bundle up to date!" if results are just filtered out.) - [ ] document breaking change reasons? (_commit comment has something at least now_) - [x] what about `bundle show --outdated`? (_it's a much simpler version ... prolly just going to leave it alone for now?_) The flags as passed to the GemVersionPromoter _change_ resolution. <=1.13.2 of bundle outdated, those flags merely filter the output, with no influence on resolution. If the lockfile is set to foo 1.0.0, and all of the following exist: 1.0.1, 1.1.0, 2.0.0, then <=1.13.2 bundle outdated currently will show: `foo (newest 2.0.0, installed 1.0.0)` <=1.13.2 `bundle outdated --minor` simply filters away that line and won't show it. With these changes, `bundle outdated --minor` would be fed to the GemVersionPromoter and actually only resolve `foo` up to `1.1.0`. This gist shows how it currently works, filtering the output: https://gist.github.com/chrismo/0bc6cfa00f539787101a9a2c900616d3 It's unfortunate timing. They were only added in 1.12 ... I'm biased, but feel like the affect the flags have on resolution is of greater value, and would be better to keep in sync with how they work fed to the `bundle update` command as of 1.13, and we could add new --filter-patch flags to replace what they do currently. IIRC, there was some confusion at the time that Andre perhaps even thought these flags as of 1.12 would be affecting what the newest would resolve to, instead of just filtering the output, so - _if_ I'm remembering correctly, that's also influencing my opinion. But, I can be swayed by the breaking behavior argument. from @indirect in [this comment](#4841 (comment)): "IMO, this is what we were trying to do in 1.12, and failed to do because resolving is complicated. :/ I would be okay with this change on the grounds that the previous flags were documented so it sounded like they cause the new resolver aware behavior. 👍"
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
See this case: https://github.com/chrismo/bundler-cases/blob/master/cases/issues/bundler-5076.rb
If your gem file only has a major increment available, and the
--minoror--patchoptions are fed to it, it filters out the major update, but then still says, "Bundle up to date!" which isn't true.The text was updated successfully, but these errors were encountered: