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

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

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

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

@myronmarston

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

@myronmarston

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

What's the status of this?

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

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

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

@swills

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?

@drbrain
Owner

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
@drbrain drbrain removed this from the 201307 milestone
@qrush
Owner

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

@qrush qrush closed this
@swills

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.

@drbrain drbrain reopened this
@drbrain
Owner

Yep, there's no commit for changing it.

@drbrain drbrain added bug and removed feature labels
@qrush
Owner

Maybe we should just remove the ~> then?

@drbrain
Owner

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

@Elffers Elffers referenced this issue from a commit
@Elffers 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
@Elffers Elffers referenced this issue from a commit in Elffers/rubygems.org
@Elffers 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
@Elffers Elffers referenced this issue from a commit in Elffers/rubygems.org
@Elffers 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
4579c5b
@Elffers Elffers referenced this issue from a commit in Elffers/rubygems.org
@Elffers 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
3dc7fbc
@Elffers Elffers referenced this issue from a commit in Elffers/rubygems.org
@Elffers 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
2f8717d
@Elffers Elffers referenced this issue from a commit in Elffers/rubygems.org
@Elffers 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
30bf878
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.