Runtime error w/ Ruby 1.8.7 & Addressable >= 2.4.0

[davidbegin]

No description provided.

[davidbegin]

@PikachuEXE @bblimke @matthewrudy how about something like this?

The couple things I am not sure of:

• moving Addressable out of the gemspec and into the Gemfile
• having the 1.8.7 Gemfile at the root of the directory

[matthewrudy]

is that deliberate?

the other mentions use < 2.4.0

[davidbegin]

Ah thanks, that was a mistake! coding too late at night. I'm pushing up the fix now

[matthewrudy]

@davidbegin I think that's fine

[davidbegin]

Alright 3rd times the charm! @bblimke could you please look over this and make sure everything looks good for a release.

Since I have done a couple rapid releases right in row, I'd really like to get this one right!

It all is good. Then I will release this 1.22.6 and yank 1.22.5

[bblimke]

I don't think addressable dependency should be removed from the gemspec.

WebMock does depend on addressable and one would expect addressable to be installed if it's missing.

Removing it from gemspec will also prevent bundler from correctly figuring out dependencies.

Gemfiles are only used for development and for Travis. The focus is on end users who use WebMock.

[PikachuEXE]

If requiring addressable >= 2.3.6 is suitable for even ruby 1.8, then just add back s.add_dependency 'addressable', '>= 2.3.6'
Otherwise I am not sure

[bblimke]

@PikachuEXE +1

[matthewrudy]

I think you should just roll the gemspec back to what it was before this problem.

It's really an addressable issue, and not something for webmock.

[davidbegin]

@bblimke @PikachuEXE the issue is "addressable >= 2.3.6" will not work for Ruby 1.8.7.
Because Addressable 2.4.0 drops 1.8.7 support.

So the only reason I moved Addressable out of the gemspec, is so Travis could still run 1.8.7.
Since we can't have multiple gemspecs, and we can't specify the gem in both the Gemspec,
and the Gemfile.

So alot of this confusion, is all from trying to be able to run 1.8.7 on Travis.

So maybe the most sensible thing is to:

• ditch the ruby 1.8.7 Gemfile
• move Addressable back to gemspec as >= 2.3.6
• keep the runtime check in place for Ruby 1.8.7 and Addressable
• And remove all 1.8.7 variations from Travis (which we could still run locally before releases)

[PikachuEXE]

@davidbegin
First of all, is the requirement addressable >= 2.3.6 valid (i.e. there is some thing that causes the version constraint to be put like that) under all Ruby versions?

If so, then changes made to .travis.yml in this PR is fine, for the purpose of running tests on Travis (Objective 1).
And in order to make it usable for actual user using Ruby 1.8.7, the runtime error is properly enough for notification purpose. And it's up to the user of this gem to decide whether they

• use addressable >= 2.3.6 and < 2.4.0, or
• upgrade Ruby from 1.8.x

[davidbegin]

First off, thanks @PikachuEXE for helping out so much on this issue.
This is my first time working on a project that supports so many older Ruby versions,
so alot of these problems are brand new to me, and I am learning as we go.

To your first question:

Here is the commit where the Addressable version was set to be >= 2.3.6.
ec820ec

Not a lot of context why, maybe an earlier or later commit will tell me why, but I'll have to explore.
Or maybe @bblimke knows why this change was made.

But also I do know that Addressable >= 2.3.6 & < 2.4.0 will work for ALL ruby versions.
We are just restricting Addressable, for non-1.8.7 ruby users for no real reason, which we didn't before.

So the issue with my PR is while my travis.yml changes work right now for running all the different versions,
it is only because I have moved Addressable out of the Gemspec into the Gemfile.
Which seems like a bad idea.

So I am wondering if you have an idea of how, we can have Addressable in gemspec,
and passing on Travis. That is what I can not figure out, without returning to gemspec version like this:

addressable_version = (RUBY_VERSION) > '1.8.7'  ? '>= 2.3.6' : '< 2.4.0'

and then we either build and release the gem on Ruby 1.8.7, and have the original problem.
Or build it on a later version, and then we will need to add more Runtime checks to constrain versions
of other gems (patron, manticore, http).

Sorry if I am missing some concept and making this more complicated! Just want to make sure we get this next release right!

[PikachuEXE]

@davidbegin
I have submitted #571 to show what I think it should be
But the Travis build fails :S

[PikachuEXE]

The build for #571 passes now