Using outdated shoulda-matchers version

[mkllnk]

I just noticed that we can update shoulda-matchers after removing this gem. There seem to be some incompatibilities between shoulda-matchers 4 and newer Rails versions. Since there's not much time for maintaining this gem, I'm wondering about these options:

• Remove version restrictions.
• Update Readme and archive.

[mcmire]

As infrequently as this gem is updated, I don't think removing the version restrictions would be a good idea, because it goes against expectations around gems and backward compatibility. Specifically, it means that two developers who ran bundle install on the same project on different days could get different results. I think it would make more sense to bump shoulda-matchers appropriately and then bump the major version.

[mkllnk]

two developers who ran bundle install on the same project on different days could get different results

Oh, all my projects use the Gemfile.lock to ensure that this doesn't happen. I didn't know that there are different setups where this could be a problem. So if you are happy to update, that's great.

Feel free to ignore my suggestions. The current issue is just that it hasn't been updated and that caused incompatibilities in our code.

[TastyPi]

I also ran into this issue as I thought there was a bug in shoulda-matchers, but it just turned out we're using shoulda and that pulls in an old version. I've replaced shoulda with shoulda-context and shoulda-matchers in our Gemfile to avoid this issue, but either this package should be updated or it should be deprecated with a big warning saying not to use it.

https://github.com/thoughtbot/shoulda-matchers/issues/1529

[pboling]

Yeah, this makes no sense. It used to be the case that bundler advised gem authors to not commit Gemfile.lock, but this is no longer the case. There is no longer a use case I am aware of where it is expected that developers will not be using Gemfile.lock.

Our (legacy) Gemfile (these lines haven't changed in 6 years):

  gem 'shoulda'
  gem 'shoulda-matchers'

When running bundle update, this is the resulting change:

It downgrades from shoulda v4 to v2 just so it can pull in the latest version of shoulda-matchers v5.

This is worse than having a vague version constraint that would allow bundler to "do the right thing", I.e. get the latest versions of everything it can.

I'm going to remove shoulda, and add shoulda-context, but this gem should be archived, be updated, or come with a warning.

[mcmire]

Sorry folks, we've neglected this gem it seems. I'll work on preparing a new release that upgrades this gem to the current version of shoulda-matchers and make sure that the versions of Ruby/Rails match by the end of the week.

[5minpause]

@mcmire thank you for your work. Is there any progress, yet? Do you need support?

[pboling]

@mcmire Looks like you're not at Thoughtbot anymore. Do you know if someone else will be picking this up, or are you still involved?

[mcmire]

Thanks for the ping, everyone, and sorry for the lack of response here. Things have been a bit busy lately.

I dusted this gem off again and there were some things that were pretty out of date. For one, I couldn't even run the tests anymore because it was relying on a version of Ruby that doesn't compile on recent versions of macOS anymore. Lately we've been making some upgrades to shoulda-matchers — dropping support for old Rubies and Rails and adding support for more recent ones. We are likely going to issue a new release of shoulda-matchers relatively soon, but in the meantime I've applied those same updates here.

So, I just released 5.0.0.rc1 which includes these updates and, of course, bumps the dependency on shoulda-matchers to 5.x. I'll look into seeing how much work we have left on shoulda-matchers and hopefully once we release 6.0.0 I can bump the dependency over here again and issue a proper release. In the meantime, please try out 5.0.0.rc1 in your project and let me know if you run into any issues.

[schadenfred]

I dusted this gem off again and there were some things that were pretty out of date. For one, I couldn't even run the tests anymore because it was relying on a version of Ruby that doesn't compile on recent versions of macOS anymore. Lately we've been making some upgrades to shoulda-matchers — dropping support for old Rubies and Rails and adding support for more recent ones. We are likely going to issue a new release of shoulda-matchers relatively soon, but in the meantime I've applied those same updates here.

I'm working on a project that sets gem authors up with a docker image for each version of ruby they'd like to run their gems tests against. You can run it locally or in ci -- I'm using circleci. Let me know if you think that would be helpful. Otherwise, I appreciate your work!

[chaadow]

Hi @mcmire and thanks for releasing 5.0.0.rc1

Since 6.0.0 has been released, would you mind bumping the dependency? Thanks!

[pboling]

@schadenfred Please do say more about this. I have a project of RuboCop wrappers (called rubocop-lts) for every version of Ruby going back to Ruby 1.8, and could really use this. Also I maintain a bunch of RSpec plugins which still support Ruby 1.8, since RSpec hasn't dropped it yet.

[mcmire]

@matsales @vsppedro Making y'all aware of this issue, in case you haven't seen it :)

[schadenfred]

@schadenfred Please do say more about this. I have a project of RuboCop wrappers (called rubocop-lts) for every version of Ruby going back to Ruby 1.8, and could really use this. Also I maintain a bunch of RSpec plugins which still support Ruby 1.8, since RSpec hasn't dropped it yet.

Broad strokes -- The project is called RoRo. You can think of it as a framework for writing configuration backstories and then sharing them. One of the backstories I wrote is for gem authors, but I think I'm the only one who has used it.

I haven't had to test any of my gems against ruby 1.8, but I looked around and found some alpine docker images with it, as well as some bigger ubuntu based ones. image size ma may not be such a big deal depending on what you'd want to use for ci. Do you have experience with CircleCI? Do you have a preference for something else?

Which of your repos would you want to set up first?