WIP: v2 changes #153
Open
WIP: v2 changes #153
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I aimed to keep all the commits small. They're all basically one change, though dba8bdf was a very large commit due to switching all the existing specs to the Rspec 3 DSL syntax. I followed the official guide for that, including using the transpec gem to auto-convert the specs, which worked shockingly well. |
- update top section (encoding pragma, load path manipulation) to modern ruby standards - cleanup dependencies: for not mostly noting current versions along with their release date. Also removed a few dependencies that are unnecessary, e.g. builder, which we don't directly depend on,
Changelog here: https://github.com/flori/json/blob/master/CHANGES.md Main note is that 2.0.0 dropped support for ruby 1.9.x
The cap we had in place wasn't really meaningful since the 1.0 series started in April 2011 and has seen 13 minor releases
Ostensibly, we aren't using this. It's required, but none of the highline methods seem to be invoked in our code
Again: this cap wasn't terribly meaningful. This gem has been on the 3.x series since August 2011 and is stable enough it's unlikely to see a 4.0 anytime soon
- temporarily drop guard-rspec, it's pulling in ruby-dep which doesn't like ruby < 2.2.5 - we don't need to name both simplecov and simplecov-rcov since the latter depends on the former - grab ci_reporter_rspec rather than ci_reporter
Test run fine with the latest version
Take a chainsaw to some cruft that's accrued in here over the years - Coverage block can be simplified and shortened - We don't need to monkey patch a logger in anymore - don't re-require gems named in the gemspec - Drop the load path manipulation - rspec 3 uses `config.color`
No obvious breaking changes between 0.9.x and the current 0.15.x series
Catch MultiJson::ParseError exceptions and return a SparkApi::InvalidJSON exception instead
Faraday supports this and passes it through to the underlying Net::HTTP interface. There's little to no reason not to specify something reasonable here. If clients can't connect in 1000ms, there are likely some problems with the network in one fashion or another.
Bundler comes with it, and they already support ruby 3.0
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
this will probably be a long-running PR while I tie up all the loose ends I'm hoping to tie up, but I figured I'd throw this up and let TravisCI run the tests while I tinker.
I started a v2.0 milestone a while ago with some goals, but in general, I'm looking to get all the dependencies up to date, make some breaking changes (e.g. merge the
ListingCart/Collectionmodels) that have been on the roadmap for a while, and collect a number of new models from our internal codebases that can be extracted here.closes #131
closes #133
closes #139