Repository navigation
Gem::Requirement add SemVer operator #1919
Description
I'm would like to suggest a feature.
My current problem is SemVer is too hard to implement.
This issue is related to:
- Publishing a library
- The command line
gem
I will abide by the [code of conduct] (https://github.com/rubygems/rubygems/blob/master/CODE_OF_CONDUCT.md). ✅
This is regarding the Gem::Requirement class, documented at https://ruby-doc.org/stdlib-2.1.0/libdoc/rubygems/rdoc/Gem/Requirement.html
This issue proposes to add a new operator to compare Semantic Versions. See http://semver.org/
Currently we can express:
rack ~> 1.2.1 (which means >= 1.2.1 and < 1.3.0)
But it will be more valuable if we can express
rack ~~> 1.2.1 (which means >= 1.2.1 and < 2.0.0)
Activity
simi commentedon May 10, 2017
Why not to use
rack "~> 1.2", ">= 1.2.1"orrack ">= 1.2.1", "< 2.0.0"?fulldecent commentedon May 10, 2017
The default case (in 2017) should be to naively assume semantic versioning. And the default case should be the simplest to express.
perlun commentedon Sep 11, 2017
I agree with @fulldecent in theory. I'm not sure the ~~ operator is the most elegant way to express it, but it's definitely a good idea to think about "how do we make it easier to support SemVer-compliant scenarios", since these should be the default by now...
fulldecent commentedon Sep 12, 2017
I'll say it just because someone else is thinking it.
PROPOSAL
Change
~>from current meaning to become SemVer operator.IMPLEMENTATION
~> 0.xmeans< 1.0and~> a.x.ymeans>= a.x.y and < (a+1).0.0DISCUSSION
Do this change with the next major release of rubygems, i.e. version 3.0. Document it as a breaking-change. Do it the Apple way (just make it better, people get better things by default) and not the PHP way (make everyone add a line at the top of every file they ever create for entire future of the language). What could possibly go wrong?
perlun commentedon Sep 12, 2017
Some suggestions:
>= a.x.y and < (a + 1).0or something like that, to make it super-obvious that this is what you mean.-a valid character in version strings... If/when we do this change, I think we should change the regexps so that all SemVer versions are valid gem versions. Like you say, we probably won't have full SemVer compliance just because of that, but there are a lot of smart people that will be happy by this move and roll up their sleeves to make it work as expected.Problems with this proposal
Rubygems is currently shipped together with Ruby (I don't know if this has technical or practical reasons). Ruby 2.5.0 (or other 2.x versions) can really not bring in a new major version of Rubygems that breaks backwards compatibility with the ecosystem at large, so it will likely have to be an opt-in (rubygems
3.0.0-beta.0which can be installed bygem update --system 3.0.0-beta.0) for quite a long time. It could then be launched world-wide with the release of Ruby 3.0 (whenever that will be ready), but even so, I would guess that Matz and others would be quite reluctant to force this big a change onto the community. It is a breaking change and will get some people quite upset.Having that said, we do need to start thinking about Rubygems 3.0 at some point and I think these kind of changes are an excellent fit for a new major version.
Advantages of this proposal
duckinator commentedon Sep 12, 2017
I thought the
~>operator was for semantic-ish versioning to the precision you specified. That is,~> 1.2would match 1.y where y >= 2,~> 1.2.3would match 1.2.z where z >= 3, etc. Is that not the case? Or is there some reason this isn't sufficient?Not trying to dismiss the issue; I just want to get a better understanding for what the problem actually is.
(EDIT: fixed inaccurate phrasing.)
fulldecent commentedon Sep 13, 2017
@perlun Thank you, proposal updated. Perhaps the way forward is a
feature/sem-verbranch and it will get in when it gets in. Ruby is looking dated without it, maybe that is motivation enough to merge for 3.0 and maybe it's not.@duckinator You are correct. The problem here is that nearly everybody want to express dependencies as "version x.y.z or something guaranteed to be backwards compatible with it". Luckily semver does that but unfortunately most people will use the easiest thing that is close enough (i.e.
~>).perlun commentedon Sep 15, 2017
There are other things that makes Ruby dated in my eyes as well... The lack of optional typing is one of the things that frustrate me the most. Even Python supports it since version 3.5 (released 2 years ago). Ruby remains stubborn and does not want to change, even though the rest of the world is moving on.
But, yes - it would be great to have this supported. Maybe you should make an experimental branch with it and see how hard it is? There are probably "unknown unknowns", things that we don't know of yet that will break if we do the change, but things that we aren't aware of yet. Starting to work on the implementation will usually make such things come out in the light.
fulldecent commentedon Sep 15, 2017
My goal with this issue to raise awareness and gain consensus on the issue. If we can achieve that, I can look towards implementing this. I'm barely a Ruby user, let alone developer, so it might not be the best implementation but it will work.
deivid-rodriguez commentedon Jul 20, 2018
What about using something like
^1.2.1for this new operator? I think this is whatnpmuses so people familiar with that tool would see it as natural.indirect commentedon Jul 20, 2018
I am in favor of adding a new operator for this, especially if it matches an existing operator from another language. 👍🏻
deivid-rodriguez commentedon Jul 26, 2018
It'd be nice if an
npmguru confirmed, but when I checked I understood~1.2.1as bundler's~> 1.2.1, and^1.2.1as the potential new operator. To be "consistent" withnpmand our current operators, this new operator would need to be^> 1.2.1. But that really hurts my eyes, I'd go with^1.2.1just likenpm.illegalnumbers commentedon Sep 20, 2018
Is this still needing work? Open for contributions?
deivid-rodriguez commentedon Sep 21, 2018
I think this is open for contributions, yeah! I also think a new operator is the way to go,
~>should not change meaning at this point.illegalnumbers commentedon Oct 4, 2018
Cool I'll try to follow the NPM standard.
illegalnumbers commentedon Oct 4, 2018
Might take a look next week.
illegalnumbers commentedon Oct 10, 2018
So I might take a look on Thursday - where should I get started to begin? Excited to contribute! :)
perlun commentedon Nov 5, 2018
@illegalnumbers
Fork & clone the project, make sure you can run the tests. Add a new test describing the newly added functionality. Run the tests, ensuring that your test fail.
Then, start trying to find the locations in the source code that need to be adjusted to support the new test cases. (Where this is, I cannot tell exactly; I'm only vaguely familiar with the Rubygems source code. You will have to figure it yourself or ask specific questions once you have done the previous steps, I think)
And, welcome to the community! 😄
fulldecent commentedon Dec 28, 2022
Thank you, yes, this is a generalization of that issue. Good to proceed there.
deivid-rodriguez commentedon Dec 28, 2022
I think you meant to post this at #6211 🙂
fulldecent commentedon Dec 29, 2022
Here is also a much easier way to address 80% of this issue without changing the language:
rubygems/rubygems.org#3318
And then we can append/change the language later.
hsbt commentedon May 14, 2026
I have no plan to add this. see #7972 (comment)