| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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](https://github.com/bundler/bundler/pull/4841#discussion_r82021277):
"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. 👍"
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixes #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 #5065, where the new filtering options were ignored if
the `--strict` option was used.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the discussion on new 1.13 Conservative Bundle Updates (see
https://github.com/bundler/bundler-features/issues/122), some users
would like to have the same Conservative Updating (see
http://bundler.io/v1.12/man/bundle-install.1.html#CONSERVATIVE-UPDATING)
behavior available in `bundle install` when a declared dependency is
altered in the Gemfile, also available in the `bundle update` command.
This adds a new option called `--conservative` to both `bundle update`
and `bundle lock`. The option only applies on `bundle lock` if the
`--update` option is in use.
The internal flag is more descriptive as to what actually takes place:
It locks any shared dependencies from the gem(s) being updated.
This also promotes the previously added patch level options to being
shown in command-line help, anticipating a 1.14 release, to make these
public and documented.
|
| |
|
|
|
|
|
|
|
| |
Fix #4912.
The bundle lock command produces a lockfile same as bundle update but
won't install all the gems. If the `--update` option is fed to `bundle
lock` you can also specify the `--patch`, `--minor`, `--major` and
`--strict` options added to `bundle update` in 1.13.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds the ability to specify gems in `bundle lock` command via `--update` option.
After this commit, if no list is given:
```
bundle lock --update
```
will update all gems.
Or update a list of specified gems:
```
bundle lock --update devise ominiauth
```
In this way, we can use lock command for specific gems without downloading any gem.
|
| | |
|
| |
|
