This repository has been archived by the owner on Apr 14, 2021. It is now read-only.
outdated filter options don't work with --strict option #5065
Comments
chrismo
added a commit
to chrismo/bundler
that referenced
this issue
Oct 12, 2016
Fixes rubygems#4772 - Changes previous `--patch` / `--minor` / `--major` options to `--filter-patch` / `--filter-minor` / `--filter-major` and adds back `--patch` / `--minor` / `--major` as conservative the patch level update options to match the behavior of these options in `bundle update` in 1.13. This is a breaking change for the previous filtering options added in 1.12, but we're allowing it because there was some confusion as to what those options did in 1.12, some thinking that it would perform the resolution constraints that these options _now_ actually do. A problem with merging in conservative bundle update options was the pre-existing `--strict` `outdated` option, which has been in `outdated` since 1.5. `--strict` for `outdated` means to only report on newer gem versions that still satisfy declared requirements in the Gemfile. Without `--strict`, `outdated` reports the most recent available regardless of declared requirements in the Gemfile. `--strict` in `update` in 1.13 means to not allow _any_ dependency to update past the patch level option. Rather than break the longer standing `--strict` option, the new `--update-strict` option has been added which maps to the conservative bundle update `--strict` option. We can revisit this in 2.0. This also fixes rubygems#5065, where the new filtering options were ignored if the `--strict` option was used.
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. 👍"
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.
--strictonly shows the latest version of a gem that still satisfies any requirement in the Gemfile. The addition of--patch/--minor/--majorflags only works if--strictis not provided.I found this while working on #5061, so I can perhaps fix it up in that PR, too.
The text was updated successfully, but these errors were encountered: