Merged
Conversation
deivid-rodriguez
force-pushed
the
fix_comparison
branch
from
852bc6f to
4eab789
Compare
Contributor
Author
|
I rebased this PR and it hit a bug in bundler's master specs which is getting fixed in rubygems/bundler#7089. I'll rebase again once that lands. |
Closed
4 tasks
By comparing canonical versions.
deivid-rodriguez
force-pushed
the
fix_comparison
branch
from
4eab789 to
9836549
Compare
Contributor
|
I'm 👍 on shipping this as a bug fix. With the current setup (before this PR): That's really surprising - it means that currently version comparison isn't transitive. |
Contributor
Author
|
Happy we're in the same page here! 🎉 I should've probably pinged you about this before. |
Contributor
Author
|
Any more opinions here? It would be great to ship this with the next bugfix release! |
Contributor
|
👍🏻 |
bronzdoc
approved these changes
Apr 15, 2019
Contributor
|
@bundlerbot r+ |
ghost
pushed a commit
that referenced
this pull request
Apr 15, 2019
2651: Restore transitiveness of version comparison r=bronzdoc a=deivid-rodriguez # Description: This is an alternative to #2597 fix to #2595. I strongly think this is the best way to fix this, even if it _could_ create some incompatibility with some gems relying on things like "~> 5.x" being lower than _all_ 5.0.0 prereleases. As explained in that discussion, the official way that's recommended in the docs to match all prereleases is "~> 5.a", because "a" is the first string in lexicographical order. I created PRs to the two gems I found relying on this: * rails/activemodel-serializers-xml#17 * rails/rails-controller-testing#45 I would consider this a bug fix and ship it normally on a bug fix release, but I can understand if others prefer a more conservative approach. # Tasks: - [x] Describe the problem / feature - [x] Write tests - [x] Write code to solve the problem - [ ] Get code review from coworkers / friends I will abide by the [code of conduct](https://github.com/rubygems/rubygems/blob/master/CODE_OF_CONDUCT.md). Co-authored-by: John Hawthorn <john@hawthorn.email>
Build succeeded |
ghost
merged commit
This was referenced Apr 15, 2019
jeffwidman
added a commit
to jeffwidman/dependabot-core
that referenced
this pull request
Mar 31, 2022
This was added in dependabot@cdb346e as a temporary workaround until ruby/rubygems#2651 shipped. It looks like that shipped in Ruby Gems 3.1.0, and Dependabot is currently on Ruby Gems `3.2.20`: https://github.com/dependabot/dependabot-core/blob/9c090f6fe573aa3b6b05d20920c7c48f5f00403f/Dockerfile#L77 So this should be safe to remove. Note that I removed the code workaround from the original commit, but not the test cases... so they should catch any regressions.
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
5 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.
Description:
This is an alternative to #2597 fix to #2595.
I strongly think this is the best way to fix this, even if it could create some incompatibility with some gems relying on things like "~> 5.x" being lower than all 5.0.0 prereleases.
As explained in that discussion, the official way that's recommended in the docs to match all prereleases is "~> 5.a", because "a" is the first string in lexicographical order.
I created PRs to the two gems I found relying on this:
I would consider this a bug fix and ship it normally on a bug fix release, but I can understand if others prefer a more conservative approach.
Tasks:
I will abide by the code of conduct.