Don't pin dependency versions

[darbyfrey]

For discussion:

Instead of pinning all these dependencies in the gemspec we should allow them to be pinned by the service instead. I think this will help with the different upgrade conflicts we run into. We may need to pin some version in the next round of service upgrades, but I think this makes more sense from the perspective of the framework. Thoughts?

@bellycard/platform @danielmackey @alexmamonchik @ochagata @jay3dec

[shaqq]

we might consider pinning thor, just because the CLI will depend on it. in general, though, i agree

[ochagata]

Does it depend on a specific version of thor? @shaqq

[shaqq]

@ochagata it could if thor introduces breaking changes

[ochagata]

Any other dependencies that might cause it to start failing? @shaqq

[heymackey]

@shaqq @darbyfrey could you get away with a pessimistic version constraint for thor?

I'd say that active record and grape are probably other libraries that could introduce breaking changes. if they are following semantic versioning, you could constrain to the x.x instead of x.x.x?

[ochagata]

As long as the dependency isn't crucial(thor, roar), removing the constraint should be fine. Also, I agree with using the pessimistic version constraint for core gems.

[ashtonthomas]

Here is a related PR specifically for roar: https://github.com/bellycard/napa/pull/242