Gem::Requirement add SemVer operator

[fulldecent]

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)

[simi]

Why not to use rack "~> 1.2", ">= 1.2.1" or rack ">= 1.2.1", "< 2.0.0"?

[fulldecent]

The default case (in 2017) should be to naively assume semantic versioning. And the default case should be the simplest to express.

[perlun]

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]

I'll say it just because someone else is thinking it.

PROPOSAL

Change ~> from current meaning to become SemVer operator.

IMPLEMENTATION

• Document it as the SemVer operator
• Make it work like ~> 0.x means < 1.0 and ~> a.x.y means >= a.x.y and < (a+1).0.0
• There will be some edge case (semver.org is complicated) but don't worry, somebody out there will be more than happy to mark an issue and contribute a fix that makes it perfectly compliant with the entire semver spec.

DISCUSSION

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]

Some suggestions:

• I think you should change your example to read >= a.x.y and < (a + 1).0 or something like that, to make it super-obvious that this is what you mean.
• We should also fix Support for full Semantic versioning #592 at the same time. I am quite annoyed that even though I know how to create a pre-release version of my gem that complies with SemVer, I am not permitted to do so because Rubygems doesn't consider - 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.0 which can be installed by gem 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

• It brings Rubygems up to par with the rest of the world. SemVer is widely used by other communities (.NuGet for .NET, Rust crates, probably others as well). Being forced to not use it (which is currently the case with Rubygems) is annoying and makes Ruby feel old and outdated.

[duckinator]

I thought the ~> operator was for semantic-ish versioning to the precision you specified. That is, ~> 1.2 would match 1.y where y >= 2, ~> 1.2.3 would 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]

@perlun Thank you, proposal updated. Perhaps the way forward is a feature/sem-ver branch 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]

Ruby is looking dated without it, maybe that is motivation enough to merge for 3.0 and maybe it's not.

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]

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.