This repository was archived by the owner on Apr 14, 2021. It is now read-only.
Merged
Conversation
deivid-rodriguez
approved these changes
Apr 1, 2019
Contributor
|
Let me sort out the test failure here because I already investigated it in #6957. 👍 |
colby-swandale
previously requested changes
Apr 1, 2019
Member
colby-swandale
left a comment
colby-swandale
left a comment
There was a problem hiding this comment.
The version will be bumped when we merge #6957
Member
|
Sorry, i didn't mean to mark a review as "request changes". It would be good to merge #6957 that will bump the version instead of making a separate change. |
Contributor
|
For what it's worth, I prefer this PR. Smaller changes means understanding them better. For example, in this case the test failure caused by this PR helped me understand the issue better and taught me why the changes I proposed in #7089 are needed. While they were buried in #6957 I knew they fixed some issue but I couldn't recall why they were needed. |
hsbt
commented
Apr 2, 2019
ghost
pushed a commit
that referenced
this pull request
Apr 2, 2019
7089: Normalize file URIs in spec's lockfiles r=hsbt a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that bumping bundler's version in #7088 made a lockfile spec fail. ### What was your diagnosis of the problem? My diagnosis was that there was a combination of bugs that was making this spec pass, but the spec was incorrect. ### What is your fix for the problem, implemented in this PR? My fix is to change the test version the spec uses to not hit ruby/rubygems#2595, and thus reproduce the failure. And then fix the spec that was incorrect because the lockfile written had different URLs (`file://localhost/<stuff>`) from the lockfile we were checking against (`file://<stuff>`), thus tricking `bundle install` into thinking something had changed, and thus making it rewrite it with an incorrect bundler version. ### Why did you choose this fix out of the possible options? I chose this fix because it makes #7088 pass and it reduces surprises. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
Contributor
Member
|
@bundlerbot r+ |
ghost
pushed a commit
that referenced
this pull request
Apr 2, 2019
7088: Bump version to 2.1.0.beta1. r=colby-swandale a=hsbt ### What was the end-user problem that led to this PR? When we released the new version, We got the test failure or an error with a version number like 2.0.0. ### What was your diagnosis of the problem? We didn't test with new version number until release time. ### What is your fix for the problem, implemented in this PR? I did bump to the minor version in the master branch. ### Why did you choose this fix out of the possible options? We should develop with a new version number like 2.1.0. Co-authored-by: SHIBATA Hiroshi <hsbt@ruby-lang.org>
Member
Author
|
Thanks! |
Build succeeded |
ghost
merged commit
colby-swandale
pushed a commit
that referenced
this pull request
Apr 8, 2019
7089: Normalize file URIs in spec's lockfiles r=hsbt a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that bumping bundler's version in #7088 made a lockfile spec fail. ### What was your diagnosis of the problem? My diagnosis was that there was a combination of bugs that was making this spec pass, but the spec was incorrect. ### What is your fix for the problem, implemented in this PR? My fix is to change the test version the spec uses to not hit ruby/rubygems#2595, and thus reproduce the failure. And then fix the spec that was incorrect because the lockfile written had different URLs (`file://localhost/<stuff>`) from the lockfile we were checking against (`file://<stuff>`), thus tricking `bundle install` into thinking something had changed, and thus making it rewrite it with an incorrect bundler version. ### Why did you choose this fix out of the possible options? I chose this fix because it makes #7088 pass and it reduces surprises. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net> (cherry picked from commit 4cae424)
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.
3 participants
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?
When we released the new version, We got the test failure or an error with a version number like 2.0.0.
What was your diagnosis of the problem?
We didn't test with new version number until release time.
What is your fix for the problem, implemented in this PR?
I did bump to the minor version in the master branch.
Why did you choose this fix out of the possible options?
We should develop with a new version number like 2.1.0.