Lock dependency to RSpec 2.x

[michaelklishin]

Since the test suite cannot run with RSpec 3.x, it would be great to lock down the dependency and add a Gemfile so that it is easier to test with RSpec 2 while also having RSpec 3 installed.

[gmallard]

@michaelklishin - Hello. I hope that you still have this on your radar.

I am considering this PR, but have not come to a decision at this point.

I would like to ask several questions.

1) Are you aware that the original author of bundler (Yehuda Katz) recommends that Ruby gems not check Gemfile.lock into version control (that is recommended only for Ruby Applications)? His thinking can be found here:

http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/

I would ask for your comments on that please.

2) What actual problem are you trying to solve? What caused you to suggest this change at this point in time? I need details please.

3) Also, are you aware this this gem reverted a 'bundler/Gemfile' implementation at one point? See: a072575d1ef9831d7c040d1f6b7a0771b7762e21

Thanks, G

[michaelklishin]

@gmallard I'm happy to remove Gemfile.lock. The problem I'm trying to solve is: I want to run this project's tests and I was unable to do so when RSpec 3 is pulled down. I believe question 3 has the same answer as 1 :)

[michaelklishin]

Alternatively, and perhaps as a good next step, the test suite should be converted to RSpec 3.x. I'm happy to do that in the near future as our team (RabbitMQ) uses this gem's test suite among other suites to test our STOMP plugin.

[gmallard]

@michaelklishin - Interestingly another user has broached the subject of Rspec levels. See: https://github.com/stompgem/stomp/issues/114

I wondered if this PR was related to that subject.

I want some more time to think about this. I will get back to you.

Totally off topic, regarding RabbitMQ:

When I test here I typically use 'rake test' and run the unit tests against live servers. I generally test against:

• ActiveMQ
• Apollo
• RabbitMQ

Your plugin (at lease one version of it) is exercised frequently.

Thanks, G.

[gmallard]

Ideally I would like future stomp gems to:

1) Install and the specs run with only Rspec 2.14+ installed. 2) Install and the specs run with only Rspec 3.x installed. 3) Install and the specs run with both Rspec 2.14+ and Rspec 3.x installed.

I think that can be done and am going to start down that road here, but if you want to attempt that approach also please go ahead.

I would also appreciate any comments you have (pro/con) regarding that approach. And alternative ideas of course.

Regards, G

[gmallard]

@michaelklishin Can you please try the gem code:

1) In my personal clone: https://github.com/gmallard/stomp 2) HEAD of branch 'rsvertst'

and let me know if it meets your requirements for RSpec 3.

Please provide detailed feedback if this 'fails'.

Thanks, G.

[michaelklishin]

@gmallard I will give that branch a try next week. I doubt there's any value in supporting RSpec 2.x now or in the future. 3.x has been around since June 2014.

[gmallard]

@michaelklishin Yes, well., one never knows what happens to gem files after they are out in the wild.

[michaelklishin]

@gmallard your branch does work for me with RSpec 3.4. I suggest that it is merged into the mainline. Thank you!