suggests versions that are too strict #409

drbrain opened this Issue Mar 14, 2012 · 15 comments


None yet
5 participants

drbrain commented Mar 14, 2012

The "Bundler" box should promote Semantic Versioning. For rdoc 3.10 it says ~> 3.10 which matches semver. For rdoc 3.9.2 it is overly strict with gem "rdoc", "~> 3.9.2".

Instead, rubygems should promote semver with gem "rdoc", "~> 3.9", ">= 3.9.2" for rdoc 3.9.2 since rdoc 3.10 and rdoc 3.11 are all compatible with rdoc 3.9.


sferik commented Mar 15, 2012

If we implement this, we should make sure it only applies to gem versions >= 1.0, since Semantic Versioning allows breaking changes in minor versions for packages < 1.0.


qrush commented Apr 23, 2012

👍 to @drbrain, i'm meh to 👎 on caring about if a gem is over 1.0 or not, @sferik.

Let's play a game of fun facts!

1.9.3p0 :017 > Version.indexed.pluck(:number).map { |v| }.count { |v| v >="1.0.0") }
   (418.0ms)  SELECT number FROM "versions" WHERE "versions"."indexed" = 't'
 => 47548 
1.9.3p0 :018 > Version.indexed.count
   (113.1ms)  SELECT COUNT(*) FROM "versions" WHERE "versions"."indexed" = 't'
 => 200948 
1.9.3p0 :019 > Version.indexed.pluck(:number).map { |v| }.count { |v| v <"1.0.0") }
   (218.8ms)  SELECT number FROM "versions" WHERE "versions"."indexed" = 't'
 => 153400 
1.9.3p0 :020 > 153400.0 / 200948
 => 0.7633815713517925 
1.9.3p0 :021 > 47548.0 / 200948
 => 0.2366184286482075

So...only 23% of all published, indexed gems are over version 1.0.0. SemVer or not, I'd rather promote ~> usage over nothing.

I'm a fan of declaring my dependencies as ~> <Major>.<Minor> when I know a project is using semver. But plenty of ruby projects don't follow semver, unfortunately. It would really great if there was a way to tell rubygems that my project is semver-compliant so that could use this fact on the UI. It could both highlight the fact that the gem is using semver on the gem's page, and use this fact to suggest using ~> <Major>.<Minor> in your gemfile rather than ~> <Major>.<Minor>.<Patch>.

Maybe semver_compliant could be a new attribute of the gemspec? Unless there's a better/simpler way to tell if a project is semver-compliant...

One additional thought...a boolean semver_compliant attribute works well for this purpose but is fairly limited in its future flexibility. It might be better to have a release_policy attribute. semver_compliant can be defined as def semver_compliant?; release_policy == :semver; end. Users who are not using semver but do have an explicit release policy in mind can set release_policy to a descriptive string describing there policy, or a similar symbol if other standard policies emerge in the future.

swills commented Jul 24, 2012

What's the status of this?


sferik commented Sep 5, 2012

@qrush I'm not moved by your statistics. There are lots of projects that push a 0.0.1 and never ship another version. If you weighted your data by the number of downloads, I think you'd find that most popular gems (with the notable exception of rake) are >= 1.0.0 and follow Semantic Versioning.


qrush commented Sep 5, 2012

Let's wait for RubyGems 2.0's metadata to have a SemVer specific flag.

In the meantime, I think we should fix the original bug that @drbrain pointed out. Whether a gem is 1.0 or not really does not matter.


sferik commented Sep 5, 2012

Whether a gem is 1.0 or not really does not matter.

I believe it does matter. I don’t think we want to recommend a dependency specification that causes people’s applications to break. Implementing this suggestion as-is could cause a bunch of issues for people. I'd suggest we err on the side of safety.

swills commented Sep 7, 2012

I think it's important to consider that defaults matter and to try to pick defaults that encourage the best behavior. So, yes, it's important to work with the gems that don't follow SemVer, and having a semver_compliant attribute is good. Please do that. But also default it to on, and change the behavior of so that if it's not specified, it's assumed to be on.

In this way, we encourage people to move to SemVer, while accommodating those who don't.

As far as the 1.0 issue, to me, it's unfortunate that SemVer allows changing things so much below 1.0, but it does make sense and I think we should encourage people to be aware of it and bump to 1.0 when appropriate. Not sure how to do that though. Perhaps a warning on for modules below 1.0?


drbrain commented Sep 7, 2012

I agree that a semantic versioning compliant attribute should default to on. It seems most authors reasonably follow it.

@qrush qrush removed this from the 201307 milestone Nov 28, 2014

@drbrain drbrain removed this from the 201307 milestone Nov 28, 2014


qrush commented Nov 28, 2014

Sounds like this isn't a problem anymore, I haven't seen any complaints about it lately. 🔫

@qrush qrush closed this Nov 28, 2014

swills commented Nov 28, 2014

It is still an issue. Picking a random gem:

The suggestion is:

gem 'cinch', '~> 2.1.0'

so it's still defaulting to a pessimistic version constraint.

@drbrain drbrain reopened this Nov 28, 2014


drbrain commented Nov 28, 2014

Yep, there's no commit for changing it.

@drbrain drbrain added bug and removed feature labels Nov 28, 2014


qrush commented Nov 28, 2014

Maybe we should just remove the ~> then?


drbrain commented Nov 29, 2014

It shouldn't be a difficult fix, I'll se what I c do this week

Elffers added a commit to Elffers/ that referenced this issue Mar 17, 2015

Improve version specification recommendation
Previous Gemfile recommendations for rubygem version were too strict.
This recommends the latest feature release version up to the latest version of
the gem.

Fixes #409

@arthurnn arthurnn closed this in #870 Oct 18, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment