More correct requirement specifiers #45
Merged
Conversation
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
|
Actually, after having a look at #42, the current version is exactly what we want (not allow 5.0.1 prereleases), although |
|
I changed the PR to the most correct version, just in case :) |
Technically, if the rails team released a new "5.0.1.zeitgeist" prerelease version and rubygems behavior was fixed according to rubygems/rubygems#2597, this requirement would no longer do what it's supposed to do. This will clearly not happen, but I wanted to raise awareness of this xD.
4 tasks
ghost
pushed a commit
to rubygems/rubygems
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 <[email protected]>
pombredanne
pushed a commit
to aboutcode-org/univers
that referenced
this pull request
Dec 7, 2021
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 <[email protected]>
pombredanne
pushed a commit
to aboutcode-org/univers
that referenced
this pull request
Dec 7, 2021
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 <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The way prereleases are designed by rubygems is the following. The first segment containing a non numeric character is considered the begining of the prerelease part of the version. For example, in "5.0.1.x", "5.0.1" is the release part, and "x" is the prerelease part (it could contain more segments, but in this case is just one). The way versions are compared is. Each of the segments in the release part (left to right) is compared to each other (assuming 0 is one of the versions don't have the segment). If every thing is the same, the prerelease parts are compared in the same way, except that segments containing non numeric characters are compared lexicographically. That means that
5.0.1.rc1would be considered lower than5.0.1.x, and thus wouldn't be allowed here.The funny part is that this currently works the way one would expect, but it's only due to what I consider a bug in rubygems. See rubygems/rubygems#2597.