Skip to content
This repository has been archived by the owner on Apr 14, 2021. It is now read-only.

Delay deprecation of bundle config and bundle update without args #7475

Merged
1 commit merged into from Dec 13, 2019

Conversation

deivid-rodriguez
Copy link
Member

@deivid-rodriguez deivid-rodriguez commented Dec 10, 2019

What was the end-user problem that led to this PR?

The problem I was thinking about the upcoming release of bundler 2.1.0, and I'm not convinced about these two deprecations.

I'm not necessarily against them, but these command are very common IMO, and we'll be making them harder to run. Again, maybe for good reasons, but still. That will be combined with the fact that:

  • In this same release, we'll be enabling all of the other deprecations.
  • Ruby 2.7 will include bundler 2.1 and ruby 2.7 will also come with a lot of warnings about keyword arguments.

What was your diagnosis of the problem?

My diagnosis was that I think it's better to postpone these two deprecations for now. Get the other deprecations going and get user feedback about them, and then worry about these two later.

What is your fix for the problem, implemented in this PR?

My fix is to delay both deprecations.

Why did you choose this fix out of the possible options?

I chose this fix because I don't want to be too annoying to users at this moment.

@deivid-rodriguez deivid-rodriguez force-pushed the undeprecate_argless_config_and_update branch from 28dd293 to 5dc6b59 Compare December 13, 2019 10:57
@deivid-rodriguez deivid-rodriguez force-pushed the undeprecate_argless_config_and_update branch from 5dc6b59 to 89f12a9 Compare December 13, 2019 11:44
@deivid-rodriguez
Copy link
Member Author

Will merge as soon as CI passes. Thanks @hsbt 👍.

@deivid-rodriguez
Copy link
Member Author

@bundlerbot r=hsbt

ghost pushed a commit that referenced this pull request Dec 13, 2019
7475: Delay deprecation of `bundle config` and `bundle update` without args r=hsbt a=deivid-rodriguez

### What was the end-user problem that led to this PR?

The problem I was thinking about the upcoming release of bundler 2.1.0, and I'm not convinced about these two deprecations.

I'm not necessarily against them, but these command are very common IMO, and we'll be making them harder to run. Again, maybe for good reasons, but still. That will be combined with the fact that:

* In this same release, we'll be enabling all of the other deprecations.
* Ruby 2.7 will include bundler 2.1 and ruby 2.7 will also come with a lot of warnings about keyword arguments. 

### What was your diagnosis of the problem?

My diagnosis was that I think it's better to postpone these two deprecations for now. Get the other deprecations going and get user feedback about them, and then worry about these two later.

### What is your fix for the problem, implemented in this PR?

My fix is to delay both deprecations.

### Why did you choose this fix out of the possible options?

I chose this fix because I don't want to be too annoying to users at this moment.


Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
@deivid-rodriguez deivid-rodriguez added this to the 2.1.0 milestone Dec 13, 2019
@ghost
Copy link

ghost commented Dec 13, 2019

Build succeeded

@ghost ghost merged commit 89f12a9 into master Dec 13, 2019
@ghost ghost deleted the undeprecate_argless_config_and_update branch December 13, 2019 16:03
deivid-rodriguez pushed a commit that referenced this pull request Dec 13, 2019
7475: Delay deprecation of `bundle config` and `bundle update` without args r=hsbt a=deivid-rodriguez

### What was the end-user problem that led to this PR?

The problem I was thinking about the upcoming release of bundler 2.1.0, and I'm not convinced about these two deprecations.

I'm not necessarily against them, but these command are very common IMO, and we'll be making them harder to run. Again, maybe for good reasons, but still. That will be combined with the fact that:

* In this same release, we'll be enabling all of the other deprecations.
* Ruby 2.7 will include bundler 2.1 and ruby 2.7 will also come with a lot of warnings about keyword arguments.

### What was your diagnosis of the problem?

My diagnosis was that I think it's better to postpone these two deprecations for now. Get the other deprecations going and get user feedback about them, and then worry about these two later.

### What is your fix for the problem, implemented in this PR?

My fix is to delay both deprecations.

### Why did you choose this fix out of the possible options?

I chose this fix because I don't want to be too annoying to users at this moment.

Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
(cherry picked from commit 69a88cf)
@jrochkind
Copy link
Contributor

jrochkind commented Dec 27, 2019

Personally I think bundle update without args ought to be part of recommended workflow.

If all dependencies were using semver, and all dependency requirements (whether in Gemfile or included gemspecs) locked to semver-compatible minor version (eg ~> 1.0.0), then bundle update without args would be the right command to update your entire dependency tree to latest versions possible with no backwards compat. Thus getting all bugfixes, security patches, and other improvements, without having to individually evaluate each dependency.

It was my understanding that this use case was in fact one of the main motivations of bundler originally, and has always been a recommended usage pattern.

Of course, in fact not all dependencies may use semver, plus there can be bugs in dependency requirement specs or releases. Still, when you have a good test suite, it is still often very useful to run a bundle update without args, then see how your tests do.

I was confused and disconcerted to see bundle update deprecated, and pleased to see this has been at least temporarily backed off from. I would suggest rethinking the deprecation in general.

I think argumentless bundle update was originally intended as a common and recommended usage pattern, and intentionally available with a simple and common invocation, not meant to be an uncommon edge case requiring an additional argument, harder to find. It was made the default behavior of argument-less bundle update, because it was recommended and expected to be common and easy to find. And I think this remains advisable. Obsoleting existing/historical documentation and tutorials of bundle update (which will remain findable on the web by many), and hiding what should be an advisable usage pattern behind a somewhat obscure argument, will not improve the situation with confusion over bundler usage.

I think the original motivation (#5722) was mistaken; If you are using version control with your Gemfile.lock, as is both recommended and I believe nearly universal in actual practice, there is nothing especially dangerous or "destructive" about bundle update.

This pull request was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants