This repository has been archived by the owner on Apr 14, 2021. It is now read-only.
Fix sticky options deprecation #7006
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Feedback appreciated in general, but specially with wording of the deprecations! |
5 tasks
Merged
The deprecations will lead to some "true positives" where users will use `bundle config` and remove the flag, and some "false positives" where users will be fine with the option not being remembered but still want to use the flag on a per command basis. Whatever the case, we need to tell users how to get rid of the warning once they learn and get ready for the new behavior. Otherwise it's going to get super annoying!
Under the previous code, once we stop remembering options, these flags would be automatically removed without deprecation. Instead, first deprecate the options in bundler 2, then remove them and stop remembering them in bundler 3.
deivid-rodriguez
force-pushed
the
fix_sticky_options_deprecation
branch
from
b986e2d
to
6223492
Compare
|
Going in as per the plan outlined in #6975. @bundlerbot r+ |
ghost
pushed a commit
that referenced
this pull request
Mar 12, 2019
7006: Fix sticky options deprecation r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that deprecating sticky options is currently "useless" since we are removing the flags where the stickyness makes a difference at the same time. So, we don't help users adapt to (and understand) our changes. ### What was your diagnosis of the problem? My diagnosis was that we should do this change in two steps, so that first users get a explanation about why we are removing the flags and what is the preferred alternative for them, and once nobody is no longer using these flags, we deprecate sticky options in general, since they are surprising and no longer useful, since we don't depend on them. ### What is your fix for the problem, implemented in this PR? My fix is to: * In bundler 2 (next release, 2.1 for example), print a deprecation message to warn about the removal of all the flags that currently depend on the options being remembered. * In bundler 3, remove the options and deprecate remembering command line flags. ### Why did you choose this fix out of the possible options? I chose this fix because it properly and gradually informs our users about the changes that we intend to make and why we intend to make them. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
Build succeeded |
ghost
merged commit
This pull request was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What was the end-user problem that led to this PR?
The problem was that deprecating sticky options is currently "useless" since we are removing the flags where the stickyness makes a difference at the same time. So, we don't help users adapt to (and understand) our changes.
What was your diagnosis of the problem?
My diagnosis was that we should do this change in two steps, so that first users get a explanation about why we are removing the flags and what is the preferred alternative for them, and once nobody is no longer using these flags, we deprecate sticky options in general, since they are surprising and no longer useful, since we don't depend on them.
What is your fix for the problem, implemented in this PR?
My fix is to:
In bundler 2 (next release, 2.1 for example), print a deprecation message to warn about the removal of all the flags that currently depend on the options being remembered.
In bundler 3, remove the options and deprecate remembering command line flags.
Why did you choose this fix out of the possible options?
I chose this fix because it properly and gradually informs our users about the changes that we intend to make and why we intend to make them.