Closed ABaldwinHunter closed 8 years ago
Longer term I'm sure newer simplecov versions will be important for bugfixes & features. So, if we do this now, how will we handle that eventual situation? Ask 1.9 users to lock to an older version? Maintain a 2.x version and a 1.9 version of the gem?
LGTM either way. Just thinking ahead to when this won't be tenable.
@wfleming that's a good question. The current change also probably means we won't support simplecov 1.0, right? I suppose that could be a downside for repos using that version specifically.
I think having 1.9 users lock to an older simplecov version sounds like a reasonable approach and is working here, for example.
Maybe we should go ahead and take that approach now instead?
Maybe we should go ahead and take that approach now instead?
We could document that users would need to lock their own version of simplecov
in their Gemfile
, sure. That's not much different from the transitive-locking-with-json as discussed in the simplecov issue.
Or we can release our gem simplecov locked, and then release another version with it not locked, and document that users on 1.9.3 should lock their codeclimate-ruby-test-reporter
dependency to the first version.
Which way were you thinking about?
@wfleming Was thinking
We could document that users would need to lock their own version of simplecov in their Gemfile, sure.
because it seems slightly more straightforward.
WDYT?
@ABaldwinHunter fine by me!
closing in favor of https://github.com/codeclimate/ruby-test-reporter/pull/120
Some later versions of simplecov effectively don't support ruby 1.9.3 due to a loose json dependency that picks the latest version of
json
:See full explanation of issue: https://github.com/colszowka/simplecov/issues/511
For now, lock to earlier version of simplecov.
@codeclimate/review