This repository was archived by the owner on Apr 14, 2021. It is now read-only.
Git based sources and custom sources deprecation#7000
Merged
9 commits merged intomasterfrom Mar 12, 2019
Merged
Conversation
5 tasks
deivid-rodriguez
changed the title
Merged
Classic problem: comments do not get as curated as code, so they no longer make sense. I prefer to remove them and try to keep the code self-explaining and in good shape instead.
This allows us to get most of the DSL related deprecation specs passing.
To make sure all cases are covered.
And thus its removal even further.
For now, warn only users that are opting out that the setting will be removed in the future.
deivid-rodriguez
force-pushed
the
http_and_custom_sources_deprecation
branch
from
9f53723 to
c3cbd4b
Compare
Bundler 3.0 was incorrect according to the new plan of migrating to https sources first, and then removing custom sources.
Contributor
Author
|
I haven't got any reviews here, but @indirect agreed with this plan on #6975, so I'm doing this. As with any PRs that I self-merge, please feel free to leave any feedback after-merge and I'll try to address them. @bundlerbot r+ |
ghost
pushed a commit
that referenced
this pull request
Mar 12, 2019
7000: Git based sources and custom sources deprecation r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that our plan for deprecating using `git` instead of `https` for custom sources under the hood, and to deprecating those custom sources itself was unclear. ### What was your diagnosis of the problem? My diagnosis was that we should give contradictory/confusing deprecation warnings to users, so we should do this is several steps. ### What is your fix for the problem, implemented in this PR? My fix is to implement the following plan: * In bundler 2 (next release, 2.1 for example), start using https by default for the custom sources (`:github`, `:gist`, `:bitbucket`), and deprecate setting the `github.https` setting to false. * In bundler 3, make the setting `github.https` a noop, using `https` nevertheless, and go ahead and deprecate the sources. ### Why did you choose this fix out of the possible options? I chose this fix because it's the friendlier path I could think of for our users. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
Build succeeded |
ghost
merged commit
ghost
pushed a commit
that referenced
this pull request
May 5, 2019
7142: Fully switch to https sources r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that in #7000 I implemented a plan to migrate to https source by default and deprecate github/gist/bitbucket builtin sources, but I changed my mind and I think it's overkill. The reasons I changed my mind are: * We [actually announced the switch](https://bundler.io/blog/2019/01/03/announcing-bundler-2.html) and the fact that it didn't happen was not intented. So this can be considered as fixing a bug. * We have warned non https git sources for ages https://github.com/bundler/bundler/blob/a6533c0fe6541cc929f895ee0b7a9b673d34cb4d/lib/bundler/source_list.rb#L144-L153 I think people should be ready by now. Also, we introduced a new setting `github.https` that seems to do essentially the same thing as `git.allow_insecure`. ### What is your fix for the problem, implemented in this PR? My fix is to take the initial approach of #6911 and actually do this in the next release. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
This was referenced Apr 30, 2020
This pull request was closed.
This file contains hidden or 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
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
1 participant
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 our plan for deprecating using
gitinstead ofhttpsfor custom sources under the hood, and to deprecating those custom sources itself was unclear.What was your diagnosis of the problem?
My diagnosis was that we should give contradictory/confusing deprecation warnings to users, so we should do this is several steps.
What is your fix for the problem, implemented in this PR?
My fix is to implement the following plan:
:github,:gist,:bitbucket), and deprecate setting thegithub.httpssetting to false.github.httpsa noop, usinghttpsnevertheless, and go ahead and deprecate the sources.Why did you choose this fix out of the possible options?
I chose this fix because it's the friendlier path I could think of for our users.