Bump yard dependency to ~> 0.8.5

[snusnu]

@dkubb we need this merged in order to update devtools yard dependency too.

[snusnu]

@dkubb i've pushed the bump to devtools already, depending on my fork for now. still, it'd be cool if you could merge it in fast :)

[snusnu]

@sferik thx a lot!

[sferik]

@snusnu No problem. Do you need me to release gem version 0.9.3?

[snusnu]

@sferik i guess we need some time to fix breakage in dm2 gems, that stems from your backports bump to 3.0.3. Currently, none our gems bundle as all of them depend on backports ~> '2.8.2'.

@dkubb thoughts?

[sferik]

@snusnu I didn’t realize that change would have cascading consequences. I’m happy to revert it, if that’s the best course of action.

It looks like backports 3.0 added the following Ruby 2.0.0 features:

• Struct#to_h, NilClass#to_h, Hash#to_h
• Hash#default_proc = nil
• OpenStruct lib

As well as 1.8.7’s Enumerator#with_index.

Is there any reason not to use the latest backports across all dm2 gems?

[snusnu]

@sferik no, the goal definitely is to use the latest version. i would consider reverting the bump as the absolutely last option. it's just that it will take us some time to bump all the dependent gems (we use yardstick in https://github.com/datamapper/devtools and all dm2 components depend on devtools), see if their specs still pass, and if not, update codes accordingly.

[sferik]

@snusnu Even though it’s a major version bump, backports 3.0 should be fully backward-compatible with 2.x, so upgrading should be a relatively easy exercise.

[dkubb]

I wonder if we should just have a backports dep of ~> 3.0' across our DM2 gems. It's pretty stable and @marcandre tests it against rubyspec too. I rarely encounter bugs in it and when I do they're easy to make patches for and get applied quickly. Releases are frequent enough that it's not too much of a concern for me.

[dkubb]

One thing I toyed with is having a dep like this in my Gemfile:

gem 'backports', '~> 3.0', '>= 3.0.3'

This should allow anything in the 3.x series, but it must be greater than or equal to 3.0.3. The idea would be to keep the second number ever-increasing to indicate the last version that the gem was tested against. Some dependency conflicts would be removed, and the worst case situation is one gem would specify something newer than another gem has been tested with. We're releasing fairly frequently so this drift would probably last no longer than a week or two anyway.

I recall trying this syntax in a Gemfile once before and it didn't work as expected, but I'll chalk that up to a possible misunderstanding on my part. Just to verify it worked the way I thought it would I tried the following experiment:

require 'rubygems'

requirement = Gem::Requirement.new('~> 3.0', '>= 3.0.3')

requirement.satisfied_by?(Gem::Version.new('3.0.3'))  # => true
requirement.satisfied_by?(Gem::Version.new('3.0.4'))  # => true
requirement.satisfied_by?(Gem::Version.new('3.1.0'))  # => true
requirement.satisfied_by?(Gem::Version.new('3.9.9'))  # => true
requirement.satisfied_by?(Gem::Version.new('4.0.0'))  # => false
requirement.satisfied_by?(Gem::Version.new('3.0.2'))  # => false

I have to verify this with a Gemfile, but it should work there too.

[sferik]

@dkubb If you want to specify multiple version constrains in a Gemfile, I believe you need to use an array, like this:

gem 'backports', ['~> 3.0', '>= 3.0.3']

[marcandre]

Just wanted to apologize for the buggy releases yesterday. I should probably yank 3.0.0 - 3.0.2, even though they were out for only a couple of hours. Would that help?

I've taken step so that it does not happen again with some tests on travis.org: https://travis-ci.org/marcandre/backports

I have not integrated RubySpec yet, but that would be the goal, ideally.

BTW, the major version change is not really because there's any backward incompatibility, but more because there's a target change as to what require 'backports' means (and 2.8 was getting high :-) ). Comments welcome on the versioning scheme! I'm usually logged on #freenode.

[dkubb]

@marcandre oh, I don't think any of us hit the problem with the bug yesterday. We more or less were tracking backports up to 2.8.2 using ~> in a bunch of gems and we were thinking about coming up with a dependency scheme that would allow us to be a bit more flexible. With the release of Ruby 2.0 I'm not surprised that there's been a few releases lately.