Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

rubygems.org suggests versions that are too strict #409

Open
drbrain opened this Issue · 15 comments

5 participants

Eric Hodel Erik Michaels-Ober Nick Quaranto Myron Marston Steve Wills
Eric Hodel
Owner

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.

Erik Michaels-Ober
Owner

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.

Nick Quaranto
Owner

:+1: to @drbrain, i'm meh to :-1: 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| Gem::Version.new(v) }.count { |v| v >= Gem::Version.new("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| Gem::Version.new(v) }.count { |v| v < Gem::Version.new("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.

Myron Marston

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 rubygems.org 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...

Myron Marston

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.

Steve Wills

What's the status of this?

Erik Michaels-Ober
Owner

@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.

Nick Quaranto
Owner

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.

Erik Michaels-Ober
Owner

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.

Steve Wills

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 rubygems.org 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 rubygems.org for modules below 1.0?

Eric Hodel
Owner

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

Nick Quaranto qrush removed this from the 201307 milestone
Eric Hodel drbrain removed this from the 201307 milestone
Nick Quaranto
Owner

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

Nick Quaranto qrush closed this
Steve Wills

It is still an issue. Picking a random gem:

http://rubygems.org/gems/cinch

The suggestion is:

gem 'cinch', '~> 2.1.0'

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

Eric Hodel drbrain reopened this
Eric Hodel
Owner

Yep, there's no commit for changing it.

Eric Hodel drbrain added bug and removed feature labels
Nick Quaranto
Owner

Maybe we should just remove the ~> then?

Eric Hodel
Owner

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

Hsing-Hui Hsu Elffers referenced this issue from a commit
Hsing-Hui Hsu Elffers 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
7effd53
Hsing-Hui Hsu Elffers referenced this issue from a commit in Elffers/rubygems.org
Hsing-Hui Hsu Elffers 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
50b23b9
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.