Skip to content
This repository

rubygems.org suggests versions that are too strict #409

Open
drbrain opened this Issue March 14, 2012 · 11 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
qrush commented April 23, 2012

:+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.

Erik Michaels-Ober
Owner

:+1: to @myronmarston's suggestion.

Steve Wills
swills commented July 23, 2012

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

I'd argue that it does matter. Many gems predate SemVer and use a custom versioning scheme that does not guarantee backwards-compatibility between minor versions. For example, some gems follow the versioning scheme of Ruby itself, where patch versions are intended to be backwards compatible, but minor versions are not (e.g. Ruby 1.8 vs. Ruby 1.9). Implementing @drbrain's suggestion could cause issues in these cases.

Without knowing whether a gem follows SemVer, it's impossible to know what version constraint to suggest. Without that knowledge, I'd suggest we err on the side of safety.

I suppose I'd be okay with implementing this idea if we added a caveat above the Gemfile suggestion that said something like: "If this gem implements Semantic Versioning, you should specify the dependency like this:". In that case, I still think we should use ~> X.Y.Z for gems with a version < 1.0.

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.

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.