Reenable deprecation specs (and make up a plan) #6975
Conversation
|
I gave it a little more thought and I think the deprecation is fine with the updated message. But maybe we should also stop printing the deprecation if the user explicitly sets the feature flag to |
deivid-rodriguez
force-pushed
the
sticky_options_deprecation
branch
2 times, most recently
from
d3d0441
to
776edd5
Compare
deivid-rodriguez
changed the title
|
Ok, I've augmented the scope of this PR to handle the most important deprecations and make a plan for each of them (including the deprecation of sticky options). This is because I need to make a compromise between fully isolated PRs, and keeping a sane list of opened PRs and not overwhelming other devs with review requests. This PR is still a WIP, and it's created on top of #6965. I changed the title and description of this PR to describe where I'm heading with this. |
deivid-rodriguez
force-pushed
the
sticky_options_deprecation
branch
from
776edd5
to
348b478
Compare
|
I really like this plan. I am 👍 |
deivid-rodriguez
force-pushed
the
sticky_options_deprecation
branch
from
348b478
to
d570427
Compare
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!
Since we haven't even yet deprecated the old behavior.
Classic problems, comments do not get as curated as code, so they don't currently make sense.
Not necessary since no future version will run them.
It's just too early to deprecate "Gemfile", and I don't think this deprecation was even doing that.
This fixes #6910. The idea here is that we first switch the default source to https, but not yet deprecate the custom sources, but only making them use http. On bundler 3 we can actually go and deprecate the sources.
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
sticky_options_deprecation
branch
from
d570427
to
7b44d4d
Compare
|
I have now extracted each of the steps underlined in the description to separate PRs, so they can be reviewed and discussed independently! 👍 Closing this! |
What was the end-user problem that led to this PR?
The problem was that need to deprecate stuff and we are not yet ready (not for removing it, for deprecating it!)
What was your diagnosis of the problem?
My diagnosis was we need to make a plan at least for the most important deprecations, since there's some of them are not clear how they will happen.
What is your fix for the problem, implemented in this PR?
My fix is to:
Get deprecation specs passing.Done in Fix deprecation specs #6991.Make a plan for stopping remembering options. For this, I propose the following:Extracted to Fix sticky options deprecation #7006.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.Make a plan for the removal of custom sources :github, :gist, and :bitbucket, and switching to https. I also propose to do this in 2 steps.Extracted to Git based sources and custom sources deprecation #7000.In bundler 2 (next release, 2.1 for example), start using https by default for those sources, and deprecate setting thegithub.httpssetting to false.In bundler 3, make the settinggithub.httpsa noop, usinghttpsnevertheless, and go ahead and deprecate the sources.Remove the deprecations about old rubies and rubygems, since that code will never be run.Extracted to (and expanded in) Remove unnecessary rubygems filters #6982 and Remove unnecessary ruby filters #6983.Remove the deprecation about preferingExtracted to Fix multiple gem files deprecation #6999.gems.rbtoGemfile. The deprecation was unclear, only showed when there were multiple gemfiles in the same folder, and we had decided to delay this anyways. I changed this deprecation to instead warn about having multiple gemfiles in the same folder.Why did you choose this fix out of the possible options?
I chose this fix because although a bit slow, it's the smoothest path for our users that I could think of.