-
-
Notifications
You must be signed in to change notification settings - Fork 2k
Delay deprecation of bundle config
and bundle update
without args
#7475
Conversation
28dd293
to
5dc6b59
Compare
5dc6b59
to
89f12a9
Compare
Will merge as soon as CI passes. Thanks @hsbt 👍. |
@bundlerbot r=hsbt |
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 <[email protected]>
Build succeeded |
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 <[email protected]> (cherry picked from commit 69a88cf)
Personally I think If all dependencies were using semver, and all dependency requirements (whether in Gemfile or included gemspecs) locked to semver-compatible minor version (eg 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 I was confused and disconcerted to see I think argumentless 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 |
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:
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.